The rise of cloud-native development, containers and microservices architecture signifies a new trend in digital transformation. Businesses start shifting from traditional arrangement of separate departments divided along technical competencies, to small cross-functional teams each of which is responsible for a given feature.

 

As product teams grow in efficiency, this brings up a question of delivering new features to customers, and as such the necessity of delivery platforms that would allow product teams to deploy and provision their microservices autonomously.

 

What are delivery platforms, what challenges they help companies to overcome and what makes them so compelling when building cloud-native environments – these are the questions that we are going to focus on in this article.

 

Challenges of building cloud infrastructures

 

In the course of building cloud infrastructures DevOps engineers face certain challenges that are caused by the complexity of cloud environments. Now, let’s take a look at some of them.

 

Integrating multiple tools in a single entity. Cloud Native landscape abounds with open source and product offerings. This is plainly evident from a single glance at the map of CNCF projects. From this overwhelming variety of options an engineering team has to pick the right tools, evaluate their longevity chances, and then integrate those disparate components together considering their design patterns and release cycles. Let alone operate, maintain and update the system.

 

Infrastructure versioning and testing. The resulting infrastructure set needs to be captured in code in order to automate infrastructure setup and provisioning, and track changes made to environments. Moreover, the infrastructure needs to be tested against workloads and have a mechanism of validating changes so as not to break the current system.

 

Aligning development and operation delivery life cycles. In order to keep the consistency of performance, it is essential to align the product’s release cycle with the delivery of new features to end users. To do this, a DevOps team should be guided by the specifics of the product’s usage models.

 

Customization complexity between different environments. Apart from setting up a production environment, it is no less important to spin up a testing one for the working needs of developers. Ideally, those environments should be identical but it is not always so. Managing inconsistencies between environments and configuration settings adds complexity to the assignment of DevOps engineers.

 

Compliance with business requirements. It is important to understand the requirements that business imposes on infrastructure and end product in order to gain profits. These requirements should be observed throughout all stages of product development. A DevOps team should help companies align their development process in such a way as to keep their business profitable and end users happy with the quality of products.

 

Solutions

 

Vendor-centric ecosystems (AWS, OpenStack)

 

To help their customers address the above-mentioned challenges, most of the top cloud providers come with ready-made solutions as represented by delivery platforms. The platforms are self-service and designed for product teams to build, configure and run applications on top of them. A provider company takes care of operational complexities such as management of bare metal servers and virtualization, and provides necessary abstraction levels to make the life of developers easier.

 

Creating your own platform

 

Despite ease of use and high availability, cloud platforms are cost demanding and involve the necessity of cloud expertise. This makes companies think of building their own in-house platforms where their product teams could deliver applications. The main benefit of such an approach is tailoring the platform to the company’s business needs as an internal product.

 

In-house platforms are built by dedicated teams that include cross-skilled experts from different fields (designers, developers, QA, infrastructure engineers, etc.). The duties of the platform team may in some respects overlap with the duties of DevOps as both deal with deployments, service accounts, and infrastructure. However, when it comes to building self-contained systems with explicit APIs and abstractions, it is platform engineers who build them, and not DevOps.

 

Delivery platforms

 

In general, a platform could be defined as an operating environment upon which applications can execute. However, it is more than merely an infrastructure, and tools, and APIs that you can install. It is a self-contained internal product that requires development and maintenance.

 

As platforms aim to increase the efficiency of product development, they are built with developers’ needs in mind. A compelling platform is a platform that provide developers with a self-service in terms of:

 

  • adding new microservices and infrastructure components (w/wo CI/CD);
  • provisioning for new infrastructures and initial dataplanes;
  • observability (logs, metrics, alert coverage of services);
  • permission and security boundaries;
  • component upgrade and testing.

 

By granting access to the operating environment, the platform makes product teams more autonomous in terms of deploying and provisioning applications. This in turn increases the pace of development and as such, an overall efficiency of delivering product features to customers.

 

Self-service is beyond question a must-have feature for a delivery platform. Now, what other features should a platform have to turn from an internally-managed tooling into a full-fledged competitive product?

 

Delivery platforms’ checklist

 

  • Proper documentation. Cloud-native environments are complex to build and manage. Unlike engineers who create them, infrastructure maintainers and users need detailed usage guidelines. It is essential for them to understand how to deploy microservices using the platform, perform installation upgrade and migration procedures, what to do in case of infrastructure failover, how to restore services, etc.

 

  • Versions of system components are pinned to release. If we have a finite set of software, it is a good practice to test it together for the compatibility of components (integration testing) and their flawless operation as a group (end-to-end testing). To do this, all system components that have been picked up from the cloud-native landscape should have stable versions. This helps to avoid configuration drift and builds up the system’s reliability.

 

  • Reference infrastructure contains testing pipelines. Each time that we make some changes, the platform spins up a reference infrastructure that iterates with changes and demonstrates whether they are successful or not.

 

  • Git is a single point of reference. Having all infrastructure components described in code and stored in Git makes configuration management easily traceable and simple to work with.

 

  • Proper access and secrets management. A reliable platform should be designed with security principles in mind. The principle of least privilege implies strong separation of duties and providing end users with minimum required access. Implementing strong password policy and proper management of secret data are also important parts of platform security measures.

 

  • Redundancy of key components. In order to improve the reliability and availability of a system, it is strongly recommended to duplicate critical components for supporting failover and enabling seamless recovery.

 

  • Well-planned capacity to fit scaling and cost requirements. The usage of cloud resources and infrastructure scaling all cost money, and this is critical for business. In order to save costs and stay within the budget, it is essential to understand what cloud resources and of what capacity we need for the infrastructure, and monitor the expenses on them.

 

  • Observability. We need to understand what is going on with our platform at a certain time. Centralized management of logs and metrics helps operators check the state of the platform at any time. Logs and metrics should be present both for system components (for example, DB logs, Kubernetes events, container lifecycles, etc.) and user workloads so that developers could sign in to the platform and see what’s wrong with their application.

 

Conclusion

 

As cloud-native development becomes more ubiquitous, this brings forth ample possibilities for developers in terms of deploying and provisioning applications. However, strict separation of duties on a company level and restricted access to the operating environment could make this process slow and difficult. Implementation of self-service delivery platforms makes application teams more autonomous, and as such more efficient when it comes to delivering product features to customers.