The What and How of Going Cloud Native

In my previous article, I discussed the ‘why’ behind going cloud-native. Looking at the reasons why enterprises need to look at cloud-native as a key enabler in driving forward their digital transformation, as well as getting fit for increasingly challenging market drivers.

This article will focus on the ‘what’ and ‘how’ of going cloud-native. What does it mean to be cloud-native? What are some of the difference between running cloud-native vs legacy traditional on-premise workloads? ‘How’ do you go about designing cloud-native applications? And, what application architecture is best suited to a cloud-native world?

Resetting Expectations

So, you have recently completed your migration to the cloud and now have applications powered by VMs running somewhere in the cloud, just as you did on-premise. The same application architecture, with the same infrastructure architecture as you did in your own data center.

The question here is does this sort of lift and shift approach unlock the real value and the ‘why’ behind adopting the cloud?

To make the most of the elasticity and agility possible with cloud computing, you need to evolve into the cloud-native architecture which means a different approach in the following functions:

• Application development 
• Team structure 
• Operating structure 
• Communication structure
• Technology Infrastructure

Adopting the cloud means you need to have a cloud-native mindset from the start, simply replicating what you previously did will leave you facing similar challenges as you would have whilst running on-premise.

You may see some return on space, capacity, and power – but it’s nowhere near the sort of value and innovation which can be unlocked with running cloud-native architecture.

The cloud-native approach advocates for disposable resources which are treated as programmable objects another way of looking at cloud-native is to treat the infrastructure tier as software objects as Justin Garrison refers to it as Infrastructure as software in his book ‘Cloud Native Infrastructure’

It puts a greater emphasis on development and deployment of applications, which use the nature and characteristics of the cloud as enablers to run, manage and orchestrate the application layer.

This approach means different things to different verticals, for example an Independent Software Vendor (ISV) may have the vision to transform their business to a SaaS model, rather than their current model of deploying manually on-premise – or a Managed Service Provider (MSP) wanting to take advantage of multi-tenancy to drive additional cost savings in the cloud.

Adoption of cloud-native could be the difference between survival or thriving in your industry, no matter what vertical you belong to.

Monolithic Application Architecture

To understand the cloud-native landscape, you must first understand and familiarise yourself with the way the software has been delivered and deployed. The pre-cloud software was built as a single lump of the codebase which included every feature and service all wrapped in a single application.

It is basically a single-tiered application which includes various interfaces, with data feeding into one application and commonly referred to as ‘monolith’. It matches the hierarchical organisation structure with highly complicated communication structure all working in their silo domains.

Monolithic Architecture and the Cloud

Running monolithic application architecture is the opposite to cloud-native architectures. When opting to run this type of application architecture in the cloud, it essentially works opposite to the concept of running workloads in the cloud:

• Slows down the release of product features – It is difficult to have faster release cycles because of the nature of the way the application is deployed i.e. every team trying to work on the same application if you try to enforce shorter releases it will impact code quality and ultimately result in more defects to the product;
• Operational structure – Functional changes require a complete end-to-end deployment of the application;
• Fault tolerance – A decrease in service level or a major incident will bring down the whole application and various services contained within the application, impacting whole business units;
• Ownership – Or the lack of it, as no team is fully responsible for the overall application. This will ultimately result in delivery delays of the project;
• Maintenance – Having a single application fulfilling various functional requirements will eventually get very complex to debug thus resulting in highly complicated maintenance of the application.

Despite the challenges listed above, there are many organisational and technical reasons why monoliths are easier and less risky to operate. For example, the resourcing and skill set element. The organisational structure may also be set up to suit a more monolith approach, however when you are a business or an organisation trying to transform and bring about real change then you should look at moving away from the status quo.

Micro-Services Architecture (Cloud Native Pattern)

Micro-services architecture is the ‘how’ behind cloud-native. Micro-services architecture allows for delivery and development of apps as a distributed collection of services, which in turn match perfectly with the distributed nature of the cloud.

If monolith suites a scale-up architecture which is what you typically get on-premise, then micro-services architecture allows for a scale-out architecture which is the core of any cloud platform.

This approach has a major impact on your wider business organisational structure. It transforms your whole business into building blocks that can be controlled via a standardised API, and integrate with other third-party services and products allowing you to continuously innovate and experiment leading to the development of new products and services – and all this for one-tenth of your digital workforce running out-dated monolith platforms.

Here are some of the benefits when using micro-services architecture:

• Independence – Micro-services provide clear ownership of each service, with no dependencies with other services or development teams;
• Damage limitation – Even when one service fails, it is still possible for the remaining system to function with no downtime or service impact. Recovering from failure is also quicker as each service has its own deployment pipeline;
• Diversity in technology stack – The ability to use the right technology for the right workload, freedom to upgrade to new technologies without fear of impacting the rest of the platform;
• Speed of innovation – Key benefit of cloud-native architectures allowing you to keep on top of technology as it evolves at a rapid pace.

Containerisation (Powering Micro-Services)

Containerisation raises the abstraction one step higher than virtualisation. Containers power micro-services. Containers abstract away the application platform, with its dependencies and the underlying infrastructure providing a solution to running software anywhere; From a desktop environment to a laptop, from staging to production, or from one cloud to another.

Containers allow you to decouple your application to smaller chunks and services, thus providing greater modularity to your software development. As containers only contain the required application runtime environment this makes them very lightweight, which has an impact on performance, size and manageability attributes which required when micro-services architecture.

Cloud Native Tooling 

As you move towards a cloud-native end-state there need to be changes made to run your cloud-native platform. The Cloud Native Computing Foundation (CNCF) has a list of open projects which deal with Orchestration of your containers, monitoring of services, logging, service mesh, storage, security, networking, messaging

Here are some of the open projects listed on CNCF:

• Kubernetes – Considered to be leading cloud platform for deploy and management of your container platform;
• Prometheus – A real-time monitoring and alerting tool focused on cloud-native platforms;
• Opentracing – Allows the ability to track and trace API requests which can span thousands of micro-services spread across multiple regions and zones.

Some Challenges with Going Cloud-Native 

Any sort of fundamental shift in the way things are done will have challenges, but with the right leadership and strategy, they can be overcome. Organisations need a culture shift from the top-down, with the realisation that your business success depends on the change you are driving from within.

Here are some of the challenges which may come up when moving to a cloud-native target state:

• Increased complexity – As a result of moving to micro-services, the scale and complexity can be a challenge but with the right organisational structure, and appropriate tooling, the increased complexity can be addressed;
• Resource/Skills gap – This is probably one of the biggest challenges in the market faced by enterprises looking to move into a cloud-native end-state. There are a number of ways that this can be dealt with, from re-training/coaching to looking at bringing in third-party suppliers. The culture and leadership of an organisation plays a big part here;
• Dealing with the legacy debit – The fact that you have a huge amount of investment stuck in existing legacy platforms may halt your progress. The good news is that there are ways of transforming legacy monolithic platforms to micro-service architectures, but careful analysis needs to be done on suitability prior to taking on such projects.

To conclude, the ‘what’ and ‘how’ of cloud-native is more around cloud-native architecture patterns and the mindset. These are the key ingredients when looking at cloud-native end-state. You can easily apply a technology stack which is considered to be cloud-native, and still is nowhere near running a cloud-native state.

There are compelling reasons why you should be looking at moving to a cloud-native state, which are highlighted on my ‘why’ cloud-native article.

Cloud Native Goes Beyond Automation

“Automation is not the same thing as autonomous. Automation allows humans to have a bigger impact on the actions they take. Cloud native is about Autonomous systems that do not require humans to make decisions.” – Cloud Native Infrastructure, O’Reilly Media Inc.

The statement above from the book “Cloud Native Infrastructure” by Justin Garrison, illustrates the point around cloud native being a stepping stone from automation to a more autonomous-like state, where we raise abstraction to a level where the underlining IaaS tier is abstracted from the application.