Top 5 Ingredients for developing Cloud Native Applications

Tom Höfte

Introduction

Cloud Native Applications is a trend in IT that promises to develop and deploy applications at scale fast and cost-efficient by leveraging cloud services to get run-time platform capabilities such as performance, scalability and security out of the box. Teams are able to focus on delivering functionality to increase the pace of innovation.  Everything aimed to stay ahead of the competition. Companies such as Netflix and Uber disrupt their markets by leveraging cloud native capabilities to quickly introduce their products at a global scale. Adapt or die.

This article serves as the start of a serie of articles. The goal of this initial article is to explain the why and how of cloud native applications by defining the top 5 ingredients and their rationale. In follow-up articles, I will explain the ingredients in more detail.

Why Cloud Native Applications

The world is going digital at a very fast pace in which software is eating the world. Companies need a high-performance IT organisation to survive in this software-driven world. The people and organisations involved in delivering this software are constantly looking for ways to accelerate the delivery of new software products to meet business demands.

The last 2 decades have seen developments in both technology and people & culture, all with the goal of delivering software faster and eliminating IT waste. Build automation, continuous integration & delivery to DevOps, the rise of microservice architecture patterns and supporting tools & frameworks, are all aimed to deliver software faster. But still the delivery time lines are too long, because teams must wait for infrastructure to become available.

You can automate infrastructure provisioning or try to do DevOps but if the hardware is not available or the delivery of the infrastructure depends on an external department that can't deliver at your speed, automated infrastructure provisioning won’t help.  With the rise of cloud computing fostered by the introduction of Amazon Web Services, infrastructure can instantly be made available at almost infinite scale. Teams can order and provision their own infrastructure just as quickly as booking a flight or buying books on Amazon. In addition to this cloud infrastructure is cost efficient, because it does not require a huge capital investment up front. It is pay-as-you-go. That is why cloud infrastructure is popular with start ups or innovation departments who need infrastructure to quickly try out new products at low cost.

By leveraging cloud infrastructure & services, an organisation can build cloud native applications that can be delivered cost-efficient with the speed and scalability needs of today. Going cloud native will enable an organisation to become a true high-performance IT organisation that can win. IT has entered its own Industrial Revolution.

Ingredients of cloud native applications

Having explained the need for cloud native applications, I can now define what I think cloud native applications are. The most basic definition of cloud native architectures is by looking up the definition of the adjective native:

Relating to or describing someone's country or place of birth or someone who was born in a particular country or place

[Source: http://dictionary.cambridge.org/dictionary/english/native]

Using this definition, I can define cloud native applications as applications that live in the cloud and will take full advantage of running in the cloud.  As with most IT trends no single definition will suffice, so I rather prefer to define the ingredients to create cloud native environments. Figure 1 depicts the top 5 main ingredients, except the Cloud Native Application itself, to create cloud native application architectures.

 

Figure 1 Top 5 ingredients to build cloud native applications

The ingredients are separated in the categories technology and people & culture. Building and running native cloud applications is not solely technology driven. The people & culture ingredients are key for becoming successful in leveraging the cloud to accelerate innovation. Secondly, native cloud applications can be composed of a combination of microservices and serverless functions triggered by events or exposed via APIs. Gartners defines these type of applications Mesh Application Service Architectures, MASA, in their 2017 Tech Report.

In the following sub-sections the 5 main ingredients will be briefly introduced.

Ingredient #1 Cloud Platform Automation

Of course, this is an essential ingredient as cloud native applications are born and live in the cloud. A cloud platform provides platform services for running your applications, managing your network and managing security & identity access within your cloud environment. As said before, cloud is also cost-efficient. Cloud doesn't require huge capital investment upfront to build and manage a data center. The elasticity of a cloud platform allows organisations to start small and grow limitless but only pay-as-you-go for the infrastructure. This makes cloud very cost efficient.

A cloud platform that can’t be fully automatically provisioned will not provide the speed and agility promised by running cloud native applications. You want to follow the Infrastructure- As-Code paradigm that prescribes to define your infrastructure in the same way you write software programs in code. This allows you to reuse all the widely-used best practices for testing, version control, documentation and software life-cycle management. Version infrastructure in source control and provision new environments with the correct requirements using a specific version. Fix infrastructure in code first, test the fix in a test environment and commit to version control when tests are completed after which the affected environment can be recreated from scratch instantly. Instead of fixing issues in a running environment with the risk of side-effects or environment configuration drift. In the same way, you can also add new features to environments. With Infrastructure-As-Code and adopting software development best practices, environments really become immutable, more resilient and easier to manage.

Taking this further you also want to build & test and deploy your application with minimal human interaction required. Combining this with infrastructure as code into a Continuous Delivery Pipeline will give the provisioning speed required for fulfilling the promises of cloud native applications. Imagine that you can roll out your product on new infrastructure in a new geographical market overnight by with a single click.

Ingredient #2 Serverless Functions

Serverless Functions are small, single-purpose functions that are triggered by events without the need to manage a run-time environment. With Serverless Functions it is possible to build asynchronous event-driven architectures using single-purpose microservices.  Functions are typically developed in a common language such as Java or Node.js. The name serverless is a bit misleading because your code runs also on servers, with the key difference that the cloud provider takes care of spinning up instances to run your code and scaling out under load. Therefore, Function-As-A-Service (FAAS) is a commonly used synonym. Typical use cases for FaaS are use cases that are triggered by an event in the cloud, such as the arrival of an event on a queue, media processing on arrival of a new media file in a storage location, processing log events or executing scheduled tasks.

Apart from FaaS, Cloud providers today offer lots of other serverless functions that can be used by your cloud native application. Think of services for Big Data, data storage at scale, speech recognition, IoT services and stream analysis services.  Typically, these services are built from open-source solutions. The benefit of using these cloud services in your cloud native applications is that you don’t need to manage the platform for these services, which often is complex by nature and requires specific skills. These cloud offerings enable you to focus on the functionality without the need to worry about installing, configuring and running the software.

Ingredient #3 Microservices Architecture Pattern

The promise of a microservice architecture pattern is to deliver self-contained software products that implement a single business capability that can be individually developed, tested and deployed to accelerate time to market and agility of the end product. This is a perfect match with the promises of cloud native applications.

When designing your microservices it is key to design them to run cloud native. One of the biggest challenges of designing cloud native applications is the ability to run your application in a distributed environment across application instances.  The 12-factor app design principles help you to design distributed microservices that can run native cloud. Multiple frameworks for different languages are available that help you to build microservices that comply to the 12-factor app design principles, such as the framework Lagom from Lightbend or Spring Boot in combination with Spring Cloud

Ingredient #4 DevOps Culture Change

Adapting to cloud native applications is not only a technology driven change but also requires a culture change. Automating your whole software delivery pipeline is only possible if development and operations do not operate in silos but collaborate as a team with a shared responsibility; delivering a software product from concept to grave. In practice, you will see that operations consists of platform engineers responsible for  development, automation and operation of the cloud platform and development consists of developers responsible for building the application that can run on the cloud platform.

Adopting DevOps principles is another key ingredient for cloud native applications. Multidisciplinary product teams consisting of development and operations will make sure the software & platform delivery pipeline runs with the right speed.

Ingredient #5 Cloud Reliability Engineering

The last ingredient for cloud native applications is cloud reliability engineering derived from the Google’s Site Reliability Engineering concept.  The whole concept of site reliability engineering is based on the idea of approaching system or platform administration as software engineering.

Adopting the concepts of Infrastructure as Code, as mentioned earlier, not only fully automates the platform provisioning and application deployment but also can make your platform self-healing and reliable. Transforming your Ops team to a Platform engineering team that continuously works on improving the platform reliability using the principles defined by Site Reliability Engineering is crucial for achieving this goal. This requires software engineering skills within your Ops team.

Conclusion

Cloud native applications help to stay ahead of your competition by enabling IT organisation to deliver innovation at a faster pace in a cost-efficient way. In this article, I tried to define the top 5 main ingredients for building cloud native applications in next articles I plan to dive deeper into specific ingredients.

To summarise this article. Building cloud native applications right does not mean you must choose the right technology and tools and you’re done. People & Culture aspects are even more important. Embrace DevOps and your IT organisation becomes more effective, follow Google’s Cloud Engineering principles to make your platform resilient and reliable and, finally, carefully manage the talents in your team to become a successful cloud native organisation.

 

 

 

 

 

 

 

 

Comments (2)

  1. Age Mooij - Reply

    February 8, 2017 at 3:14 pm

    I think you are over-estimating the difference between MSA and FaaS. In my opinion FaaS is just a different technical implementation of the same functional design pattern.

    When it comes to designing cloud native systems, choosing a Microservices Architecture approach is the important design choice. How you then choose to implement each individual service is an implementation detail.

    FaaS, or serverless, is a very nice tool for implementing a certain subtype of microservice, e.g. an event processor, but in my opinion it is just a tool, not a systems design approach at the same abstraction level (or as important) as microservice architectures.

  2. Tom Höfte - Reply

    February 8, 2017 at 4:34 pm

    Age,

    Thanks for your feedback. I agree with you. FaaS can be seen as a kind of Serverless Microservice or just a way to implement your microservice (I also made a note in my blog that it is a way to build microservices..). To be conceptually sound the Serverless Functions box should be encapsulated by the Microservices box and considered an implementation type. And yes, it is a less important ingredient.

    The reason why I mentioned FaaS separately is because it is a very nice feature provided by Cloud offerings, but conceptually speaking it must be placed inside the microservices box.

    Again great feedback thanks!

Add a Comment