Unlock new levels of productivity, harness the public cloud faster and more efficiently.
A Cloud Platform is a suite of tools and services built bespoke by an organisation to enable its teams to use a public cloud vendor to run their applications. The cloud platform can be a shared service, or it could be an inner-source project. Typical public cloud vendors require extensive configuration before an organisation can run its services, often increasing lead times. However, the process becomes iterative once an organisation begins onboarding new teams.
The goal for a cloud platform is to allow an organisation to leverage a cloud vendor like Amazon Web Services, Microsoft Azure or Google Cloud but maintain common standards, compliance and governance and deliver new applications and services in shorter time frames. The best cloud platforms offer a flexible approach enabling teams to build their cloud platform or use a shared service. Smaller divisions with fewer requirements may opt for the shared service, and larger divisions with more developers and more demanding operational requirements might want to run their own. The two approaches we favour are Inner Source cloud platforms and shared services.
They enable an organisation to accelerate the speed with which their divisions and teams of developers build, test and deploy code and provision cloud infrastructure services. They integrate third-party tools and set up logging and monitoring services. The cloud platform also contains the configuration to build hosting environments. Cloud platforms also integrate the various services required to run your applications and remove infrastructure once done (i.e. housekeeping for cloud infrastructure).
Amazon Web Services has Account isolation, Google has Project level isolation, and Microsoft Azure has subscription-level isolation. Organisations leveraging these cloud providers can build compliance and governance by leveraging the tools available at the account, project or subscription. From here, you can manage many different features; for example, as part of access control, you can configure that s3 buckets are always private. In addition, it is possible to require that an ec2 instance has a security group blocking all ingress traffic. Isolating users by account, project, or subscription would complement the inner source model well because the Inner Source will speed up the development of a cloud platform at the team level while also providing the necessary ability to navigate the compliance and governance hurdles.
While a single cloud platform is simpler to conceive for a rapidly growing organisation, it can hinder the development of a software product.
They make processes repeatable and enable processes to run based on events or requirements. In addition, workflows manage and integrate multiple components. For example, a software development pipeline is a form of workflow.
Infrastructure as code (IaC) enables cloud infrastructure configuration to be configured in text files and then committed to a version control system. The version control system tracks infrastructure changes and makes them more visible.
Cloud services, plus software as service tools, need integration to reduce management overhead. Integrating tools enable them to connect and share information seamlessly, increasing the value derived from them.
With the workflows, configurations and integrations, it's possible to create automation that reduces cost, saves time and increases the value each tool provides within the organisation.
Inner Source is a concept of building software within an organisation following the open-source model. Developers have access to shared internal source code they can easily fork, customise and deploy. A cloud platform based on an Inner Source framework will contain source code to integrate and deploy applications to a cloud vendor and configure the many non-functional requirements using reusable modules. Inner source development enables teams to share source to reduce the complexity of cloud platform deployments and enable them to provision their services based on their needs and include compliance and governance features. To conclude, for organisations fostering autonomous teams, Inner Source is best.
Inner Source helps teams differently; for example, assume teams part of an e-commerce division would have some tighter integration points. The build, deployment and hosting platforms will be the same. The Inner Source for these teams will consist of a common configuration module that manages the cloud platform setup for the whole e-commerce division, and each team will have its independent modules that manage each of their services. These modules would be in some kind of infrastructure as code language for example Hashicorp Terraform or AWS Cloudformation. The e-commerce division would be responsible for duplicating and modifying the original source for their own use and committing this into their repository. That is not all because once the team provisions the cloud platform they have to manage it. A team not prepared to manage a cloud platform should avoid this approach.
Shared services are a common strategy in which organisations manage the use of cloud vendors with the assistance of a shared cloud platform that they build to run different workloads for the teams internally. This shared cloud platform provides all the requirements for hosting applications and has non-production and production counterparts. The main benefit of a shared service model is cloud resources are not managed directly by developers. Smaller teams or divisions may need more staffing to own and operate a fully-fledged cloud platform. With a shared service, they can focus on business as usual.
In the previous example, we imagined an e-commerce division of multiple teams. However, not all divisions have these kinds of requirements. Shared service platforms are great for divisions and teams that would otherwise need to hire more people but don’t need to.
Book time with us to help put together a quote for professional services.