Unlocking innovation through platforms

Date: 24 July 2018

Developers have an immense creative desire to build great software and be rewarded by seeing it working in a production setting. It is arguably the most satisfying part of development – the knowledge that something you built is out there doing it. Delivering value. Fit for purpose.

Developers have an immense creative desire to build great software and be rewarded by seeing it working in a production setting. It is arguably the most satisfying part of development – the knowledge that something you built is out there doing it. Delivering value. Fit for purpose.

Developers don’t want to wait around months for infrastructure to be provisioned before they push their changes out to production. The process of taking an application through all stages of the software delivery lifecycle can be a tremendous undertaking. Environments can take months to provision and constitute a process that can be specific to each environment, not repeatable, and highly error prone. This process of provisioning ‘snowflake environments’¹ in a highly individualistic way contributes to a significant amount of delay in the delivery of software.

In ye olde IT world, provisioning of infrastructure was a very manual and expensive process that typically involved a whole slew of dense, confusing spreadsheets, multiple vendors, and, if you were lucky, something reasonably similar to what you needed and asked for.

Luckily, a lot of the process of provisioning infrastructure and configuring can be automated. The traditional types of infrastructure patterns we are likely to see in the real world – a web server, a three-tier application, a web server that uses a Redis cache – are well-trodden patterns.

What are platforms?

Platforms help extract common operational patterns and make it easy to build and deploy such that operators and developers don’t have to worry much about the operational details of standing their application up on infrastructure.

Here is my source code

Run it on the cloud for me

I do not care how

— The Cloud Native Haiku, Onsi Fakhouri, @onsijoe, Lead Engineer Pivotal

With platforms, applications become units of deployable functionality in which operational mechanisms are all handled via the platform. Whether your application needs a sidecar² database to store some state, access to a TensorFlow machine learning model³ to process an image, or needs to scale quickly to hundreds of thousands of users, platforms make this very very easy for a developer to do, typically in a self-service interface or model.

Considerations for using a platform

There are lots of platform products out there. Platforms abstract and automate common operational tasks so the developer experience is simple. Some platforms are lower level and give developers control of finer details such as networking rules or persistent store retention policies.

These platforms typically have a bit of a learning curve to them and require operational champions to ensure adoption by an organisation. Some platforms are very opinionated and easy to use, automating as much as possible for common application patterns. Choosing the right platform takes into account both the folks that will use it and understanding the applications that will be hosted on it.

Application architecture

Some platforms require developing your applications in radically different ways than the typical monolith architecture most folks are familiar with. It’s important to choose the platform that makes sense for the types of applications you are planning to build.

Are you building an ecosystem?

If you are planning on building a service ecosystem comprised of several APIs and services, then you are going to want a platform that can handle things like message queues, circuit breakers, call caching and service resiliency. You will construct applications with this architecture in mind.

With legacy applications, you might ‘strangle’⁴ functionality out of them into much smaller microservices. Some platforms dictate that you write your applications in a much different way to maximise the effectiveness of the abstraction the platform provides. These ecosystem developments require significant support from the team that builds them.

In some cases, it’s a better choice to take advantage of the 12-Factor⁵ Style of PaaS products. These PaaS products excel in making it easy to get a developer’s code out on a server. These types of platforms make operations and infrastructure provisioning a self-service model, bringing the time to put code into a production environment down to a matter of seconds.

Platforms bring big benefits

The most overwhelming reason people turn to platforms is to accelerate the delivery of value out to production with a minimal amount of operational effort. Developers can focus on delivering features above the value line, delivering business features so that an organisation can respond quickly to the rapidly changing business landscape.

Additionally, since the operational cost to try things out is dramatically reduced, a culture that values experimentation is enabled. This is an extremely powerful combination that separates high-performing teams from average teams: the ability to experiment and innovate quickly.

Along those same lines, the operational overhead to maintain a platform is significantly reduced. A company that had to maintain infrastructure for 100 different applications – each with their own distinct set of operational requirements – can now just focus on maintaining the platform infrastructure and ensuring that developers have the knowledge to use that platform. It dramatically simplifies the ‘Dev’ + ‘Ops’ equation into a self-service model that makes development a very satisfying and creative endeavour.

Reduce your problem space

If you are working on building ecosystems, you can start to build out environments that provide a library of services to new applications by default. By taking advantage of a service-oriented architecture or micro-service architecture, you can reduce your problem space to a set of small, easily solvable problems.

Once you solve those problems, you can serve that small solution up to any future applications. In the ecosystem model of software development, we are no longer dependent on waiting for test environments to be provisioned… we simply deploy our application to a specific ecosystem and we are automatically integrated with all the other services available on that ecosystem. It’s an immensely powerful architectural pattern that allows teams to grow and respond rapidly.

Platforms also unlock a whole bevy of features to developers that previously required significant operations support. Most platforms enable developers to take advantage of easy-to-use auto-scaling features so that their applications can dynamically respond to load.

Additionally, many platforms offer zero-downtime deployments of new code using different deployment patterns such as blue/green deployments⁶ or canary deployments⁷. In the event of failure of a service or deployment, platforms offer automatic rollbacks and self-healing capabilities.

All of these techniques previously required operations personnel to perform. Platforms provide turnkey solutions that allow developers to take advantage of these advanced techniques with little to no effort. Operational efficiency is increased, allowing an accelerated rate of change.

Key takeaways

Ultimately, platforms pay for themselves in multiple ways. The cost to maintain infrastructure and applications is dramatically reduced. The ability to innovate quickly and respond to the rapidly changing business landscape is an indispensable tool to maintain your competitive edge.

Choosing the right platform for your use case is essential for success. Platforms need operational champions in the organisation in which they exist. Operations teams become responsible for maintaining the platform. These champions are essential in ensuring that people are aware of how to use the platform to solve their problems and ensure that the platform is a reliable service that developers can use to deliver applications.

Links and references