image

Yet another term that has become fashion these days. Cloud Native application, wow that sounds like something great, but what does it really mean and when is it truly helpful? According to Webopedia, Cloud-native app is a term promoted by VMware to refer to apps that are installed in cloud-based virtual machines. According to VMware, cloud-native apps differ from traditional applications in several keys areas, including:

  • · Cloud-native apps use an elastic infrastructure
  • · Cloud-native apps need to provision instances of themselves through an API
  • · Cloud-native apps must be able to scale up and down at a rapid rate, with the ability to offer thousands or even hundreds of thousands of nodes or instances
  • · Cloud-native apps are autonomic in nature, with the ability to detect and work around failures, and if one or more nodes are lost, new nodes are spun up extremely quickly

According to InformationWeek, at the heart of “cloud-native” lie Linux, Linux containers, and the concept of applications assembled as microservices in containers. The least I can say is there is disagreement in the definition of the term. So, let’s look at what Cloud Native applications can do for your business and how far you need to go.

Cloud Native Applications, developed with cloud in mind

First, and everybody agrees on this, cloud native applications are developed from scratch using current tools with cloud in mind. It is difficult to transform existing applications to be cloud native as they were written for a different platform. Although there is no obligation, most cloud native applications are written in an aPaaS environment such as CloudFoundry or OpenShift.

Most will also tell you that a cloud native application is stateless. This means that all data related to the application is kept completely separate of the application code itself. This includes the pointers as to where the user is in the application, making the application code multi-tenant, in other words, capable of being executed by multiple users concurrently. Each user would have its own “data block”. An excellent article, called Cloud Native Applications (for Dummies) by Massimo describes this in more details.

Gradation in Cloud Native

Many new technologies and approaches are appearing these days. There is a gradation in the level of “Cloud Nativeness” you need for applications. We tend to group them in four groups:

  • Cloud Ready Applications
    • Applications do not require a files system or use Cloud storage APIs to store data and objects
    • Applications are self-contained, so they do not call upon external functions to execute
    • There ports and addresses are managed at the platform level, not within the application
  • Cloud Friendly Applications
    • Such applications subscribe to the 12 factors. I’ll come back to this in more details further in this blog post.
    • Applications are horizontally scalable which means they can clone some modules when additional capacity is required to respond to demand.
    • This can serve as a leverage platform for high availability as when multiple modules of the same functionality exist, if one stops unexpectingly, the others can take over. The current transaction can be lost though.
  • Cloud Resilient Applications
    • Such applications are designed for failure. The applications heal themselves in other words, they take care of problems and do not expect external facilities to do that.
    • Such applications are not affected by the failure of a dependent service
    • They test themselves proactively for failure
    • Metrics and monitoring are baked in
    • The runtime implementation is cloud agnostic
  • Cloud Micro Service Enabled Applications
    • Applications are designed with micro service architectures and principles
    • Based on AOI first design. API-first design is about a series of best practices across companies and industries that prioritize a better developer experience (DX). One way to achieve this is to commit to launching RESTful APIs and by using the RESTful API Markup Language (RAML) to describe them.

12 Factor

The Twelve-Factor App is a methodology for building software as a service. It expects such applications to:

  • Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;
  • Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
  • Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;
  • Minimize divergence between development and production, enabling continuous deployment for maximum agility;
  • And can scale up without significant changes to tooling, architecture, or development practices.

It’s build by practitioners for practitioners. It’s based on experience gained by developing software as a service applications. I can only encourage you to browse the website if you are interested in understanding this in more depth.

How far do I need to go?

As you probably realize, you have a wide variety of options here. Some of them are reasonably easy to implement, others are much more complex. And how familiar are your current developers with all these techniques. That is the question. Before you start the development of your application, think through what characteristics you expect from this application in following areas:

  • How many users do you expect to use this applications? If the number is small you don’t need the application to be stateless, if it’s 10.000’s or 100.000’s, you definitely will need.
  • How is the utilization varying over time? If it varies drastically, scalability is of the essence.
  • How important is it for this application to be always up and running. If it is critical, think about designing the application with failure in mind.
  • How much will the logic of the application or the business process it support evolve over time? If lot of evolution is expected, think about implementing a micro-services architecture.

So, you see where I’m going. There is not a good and a bad approach. It depends on what is required and in what environment the application will run. Obviously if you build an application that you want to deliver to the market as a service, you need different characteristics than if you build the next generation finance or marketing application for your own enterprise.

And containers in all this

You might ask yourself why I do not highlight containers. The reason is simple. Containers are just another target platform for the application. Obviously, if you go the micro services route, using containers makes a lot of sense as a hypervisor approach would build extreme overhead and cost in the picture. But in essence it’s a target platform that should not influence the way you implement your application as you want applications to be independent of their target delivery environments so they become easier to migrate from one environment to another.

Cloud Native Applications, a modern way to develop software

If you start developing a new application from scratch, use some of those principles and build your application with cloud in mind. But if you are evolving existing applications, you really should ask yourself whether you need such features for your applications. Implementing them is at least complex, and in the worst case might require a complete rewrite of your applications. So, it’s adamant to think through what really makes sense first and then decide what route to take.

This article was published the first time on the CloudSource blog at the end of 2015.