Platform Engineering and Different Stages of DevOps Maturity
Platform Engineering is term you might have heard of but not yet got to know what it exactly is. Platform's are a set of infrastructure that takes care of compute, persistent storage, networking and utilities such as monitoring, alerting and observability. This is a convenient way of boosting velocity in going to market for a service that is being developed. One of the popular recipe is having a compute platform at core such as Kubernetes and complementing it with cloud PaaS offering to provide things such as, messaging, storage, database or caching or similar infrastructure. If you also have pre modelled designs for high availability, geographical redundancy, security you should be having a streamlined process for launching services to production in small amount of time.
Today I wish to talk about some maturity levels in terms of DevOps automation that makes up your capability to onboard and launch services on your Platform. You might have a great platform but often times the tooling and automation behind your platform defines to ease up adoption for new services and developers using your platform. Is your platform team is required to aid developers and squads to onboard themselves and their services on your platform or are you in a state to offer "paved roads" to them that they can easily make use of and be happy with the end result. As most things in DevOps the answer is not binary and you can assess and see which stage you are at, right now. Where are you today, also should define the next milestone you should aim for, and finally achieve a cutting edge platform capability for your team and your stake holders. Without further due lets get into the different stages of maturity and what they exactly means.
Stage 1: Lack of Capability
This is a stage where your Platform team doesn't know how to solve a problem. For example a delivery squad may come to you with requirement such as, they want to have a containerized application, with need of a NoSQL database and a Redis cache. Your team at this moment, don't have a reference on how to continuously integrate this solution, how to consistently, build, lint, test, security scan, package and distribute such software. Then there is the problem of having a highly available, redundant and secure infrastructure that you can monitor, alert and observe that would allow you to operate this piece of software in a production environment.
This state is your starting point and you may be at this stage, this is the point where you may decide on some long term solutions. If you expect a lot more of similar problems down the line, you may decide on building a platform so you can have reusable solution to these requirements for workloads of same or similar nature.
Stage 2: Custom Solutions
You have now started building a solution based on the request you have received. You started developing infrastructure as code, pipeline as code, configuration as code to package and deploy the service. You may parametrize the artifacts you build to be able to accommodate different Software development lifecycle environments such as development, qa, uat, staging, production with different levels of SKUs and redundancy levels. However at this stage whatever you built is most likely bespoke and it would still be labor intensive to scale this same solution for other services.
The best solution you have at this stage is to duplicate the parametrized artifacts and alter them to fit for the next service you need to onboard and host on your platform, but it still requires a good amount of effort and it needs your platform team's direct involvement to enable the delivery squad to develop and launch their service.
Stage 3: Reusable & Central Artifacts
At this stage, you have moved all of your parametrized artifacts of pipeline, infrastructure as code, configuration as code monitoring artifacts into centralized repositories. The reusable artifacts are developed in a manner that they are highly parametrized and considered as generic modules that can accommodate a wide range of scenarios.
As a platform team you provide and maintain reference architectures that showcases a recommended way of consuming the generic modules you have developed and this provides a streamlined way of onboarding and developing a service that would by design be compliant and secure that has the serviceability and supportability requirements fulfilled from get go. This is called a "paved road", it would be the road that'd be taking has benefits in terms of being the road to production with least of resistance. It'd be encouraged and desired to take by everyone as it'd have better support from the platform team and provide convenience to developers while developing new services.
Stage 4: Automated Bootstrapping
As patterns emerges, the platform team should be able to spot certain use cases on how their platform it getting used. They may even define some baseline resources, common denominators they'd consider as a bare minimum requirements for a service. At this stage platform team would create some high level automation that leverages the distributed automation workflows they have already built in the previous stages to create high level automation workflows that'd make the onboarding and progression to production much easier and streamlined for new services.
This top level automation should can be more opinionated and should able to configured by small set of parameters such as project keyword, environments needed and small set of selections to be made by the consumer. At this stage the consumption of the automation is so easy that the consumer can be both the platform team that provides and maintains this automation workflow or the consumer can be directly the delivery squad that would be developing the service they wish to onboard and launch to production on the platform. This stage provides better velocity, developer experience as the involvement required from the platform specialist is lowered.
Stage 5: Environment as a Service
At this stage the platform team incorporates a platform orchestration tool to abstract the automation one more level and provide a way to orchestrate even more automation in one single flow. By using specialized tools, they allow to provision and maintain environments with minimal effort as orchestrator acts as a top level actor that initiates and governs the environments generated by this tool.
The environments generated, although should be fit for purpose for majority of the cases, the platform team would still be in consultant capacity to provide the "last mile engineering" to fill in the gaps and make the solutions provided satisfying all of the requirements of services if they need this assistance.
The environments generated at this stage are all adhering to "paved road" principles that are secure, compliant and reliable by design. The platform orchestrator provides a process to provision and manage the environments created with the Day 2 activities such as maintaining and updating in a high scale.
Stage 6: Internal Developer Portal
Internal developer portals, are internally available web applications that provides a self-service portal for developers to consume the "paved roads" developed by the platform team. At this stage as the consumption and governance shifts towards the delivery squads the platform and it's offering also makes a shift in maturity and model.
At this stage, the platform and it's features are considered as a product. The platform team being the custodians of the platform would still be required to educate delivery squads and provide consultancy to delivery squads to consume their offerings but their main duty is to maintain and update their platform, as a product.
Internal Developer Portal, acts as an "App Store" for infrastructure and supporting tooling for a service. The consumers are not only be able to provision resources required for their services but also be able to view the things that they own, manage and perform administrative tasks on them via using the developer portal. This stage is considered as the pinnacle of the automation & DevOps maturity that you can have for your platform and it can have an excellence level as much as you are willing to put efforts into it. Just reaching this stage as a minimum viable product is a pretty significant achievement, but from here onwards sky would be the limit.
Conclusion
In DevOps, the iterative value delivery is one of the key factors. The important thing is to have a direction to follow and align your efforts to reach the state you are aiming to reach. I have tried to give you an overview of different maturity levels for DevOps and automation capabilities, so you can asses what your organisations current level is and what target state you can aim, for your next sprint of efforts. I hope this you find this article, helpful in understanding your current state and strategising your ideal state in the upcoming future.
Top comments (0)