Table of Contents
- Overview
- Why Do We Need to Modernise Applications?
- Application Modernisation Journey
- Application Modernisation Options
- Summary
Overview
Container, microservice and cloud native are buzz words we are hearing in recent years on application modernisation news.
If your company has been in business for years relying on information technology to help operating the business, and if your company is an enterprise that wish to look into ways how to modernise your existing applications – by moving your application workloads to containers, microservices or cloud native applications, this is the article for you.
We will first look at what is container, microservice and cloud native, and then look at what are the approaches available for application modernisation.
Containers, Microservices and Cloud Native Applications
The easiest way to understand what is container is to compare it to the virtual machine (VM). I had came up the following comparison summary to help you better understand the differences between VM and container.
Note: Refer to Architecting Containers Part1: Why Understanding User Space vs Kernel Space Matters for definition of user space.
In short, container is more light weight with smaller footprint, makes it be able to scale faster and more agile compared to VM, makes it a better approach to package and run applications that required this capability.
Usually we will tend to run microservice based application in container. It is not wrong to run monolith application as container, however with the typical monolith application nature and design with large resource footprint, it will not benefit from the advantages of container.
What is microservice?
Traditional application is designed to have all the business logics and supporting services in one single application deployment unit such as one single .war or .jar file.
This is what we called monolith application.
Monolith application is heavy weight application that usually take longer time to startup and to be ready to serve requests. Monolith typically is stateful application requires traditional approach to manage and maintain the application stage, which requires specific persistent storage. Dependency of traditional poorly managed persistent storage cause the application scale poorly. Demand for better application performance regardless of private cloud, public cloud and hybrid cloud deployments drive people to start implementing application follows microservice approach.
Put it this way. Monolith application is your e-commerce application with all the required services packaged together as one single deployment unit such as shopping card service, product search service, catalog service, payment service and etc.
On the other hand, microservice tends to be designed and implemented into individual service. By end of the day, you will have shopping card as standalone service running in it’s own container, and product search service running as standalone service in a separate container, and so on for the rest of the services. These microservices communicate via API interfaces and maintain their application states using microservice-based data services.
What is Cloud Native then?
Let’s look at the definition from Cloud Native Computing Foundation (CNCF):
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.
So it is not hard to understand that container and microservice are part of the cloud native technologies. They allow companies to enable their applications to be designed, deployed, run and behave as cloud native applications.
Since we are talking about running scalable applications in public, private and hybrid cloud, it is ideal to design the applications as stateless, to ensure the applications can resume their processes as soon as they are scaled, in the event of load balancing or container failure. If stateless is not avoidable, there should be some mechanism and design pattern in place to ensure application stage is maintained and managed seamlessly.
In short, cloud native is the way to go to modernise our applications today. According to CNCF (Cloud Native Computing Foundation) survey in 2018, use of cloud native technologies in production has grown over 200%. The top three benefits of cloud native technology are faster deployment time, improved scalability, and cloud portability. If you have not started the cloud native journey this is probably the time to take a serious consideration on it.
Why Do We Need to Modernise Applications?
Do not fix if not broken. This is what we have been taught since we are young by our parents.
So what could be the motivations to modernise your applications?
Basically there are 2 major motivations, driven by business needs and changes, and/or, technical challenges, that cannot be resolved by the existing applications.
From experience, business drivers are usually the key reasons why companies want to modernise their applications. It is always easier to acquire internal sponsors support because of business needs instead of technical needs. Occasionally companies start with technical drivers turns out to realise it is always relates back to business drivers at the end of day.
The following diagram illustrates the break down of the motivations to modernise existing applications. The information is self-explained and I will not going further detail into each of them.
Application Modernisation Journey
So far we have touched on detail of container, microservice and cloud native application (CNA). We also touch on the motivations of why we should modernise our applications. Next we are going to look at what are the approaches available to modernise our applications.
Before that, let’s look at the CNCF’s cloud native trail map. Companies without experience will be hindered away when first glance at the trail map below. It seems like a lots of technologies and efforts are required in order to move your first step into the cloud native journey.
In actual fact, implementing cloud native for your applications is not as complex as you think. It will be, if you are trying to do it all alone by trying to integrate all the open source products; if you do not know that you can starts small and grow big later; if you do not know which steps in the trail map are essentials and which steps can be ignored during your initial cloud native journey.
Most of the time, you does not need to enable all the technologies outlined in the cloud native trail map. You can always starts with the most basics which is covered in section of Essentials of Application Modernisation.
Essentials of Application Modernisation
There are 10 steps in the cloud native trail map. Depends on your applications and the supporting infrastructure environment maturity, you may already meets the requirement for some of the steps, and you can move on the the next step which is revenant.
Among these 10 steps, the following diagram shows the 3 basic steps at least an organisation need to fulfil in order to enable cloud native for your applications with a supporting environment. Your current environment may have some of them in-placed and what you need to do is to identify the gaps and close those gaps before proceeding to further steps.
In here, I would like to referred these 3 basic steps as Essential of Application Modernisation.
Containerisation
Convert or migrate your existing application to container. It is fine to run your existing monolith application as container at the initial stage but eventually it is recommended to decompose your existing monolith applications to microservice applications.
You should try at best to avoid running your applications as monolith container applications. The effort of migrating monolith applications at later stage is always outweighs the effort of doing so in the beginning stage.
There are many approaches that you can use to design microservice based application, one of the well known approach is to follow the Domain-Design Pattern (DDD). DDD is an approach to software development that centers the development on programming a domain model that has a rich understanding of the processes and rules of a domain. The approach is particularly suited to complex domains, where a lot of often-messy logic needs to be organized. You may refer to Martin Fowler’s Domain-Driven Design for more information.
Results of DDD exercise provides you a clear picture of how your cloud native applications and services should looks like and how they relates to each others, as well as all the supporting services. With this information, most of the time you will be able to decide as a team how should you plot your next step. For example you will be able to prioritise which domain of application should be migrated to cloud native first and which new services or supporting services should be implemented first. This empower your team to have choice to decide whether to pilot small portion of your applications instead of the entire applications ecosystem and ripe the success of cloud native in shorter timeframe.
CI/CD
Depending on the scope and size of the applications, modernising the existing applications potentially results in hundreds if not thousands of containers. It will not be possible to manage the application delivery and deployment as what you are practicing traditionally.
You need automation.
You need to look at how you can automate the application deployment and delivery process such as application build & packaging automation, application deployment automation to multiple environments such as TEST, UAT and Production, as well as application versioning, rollout and roll backs automation.
This is what we refers to as CI/CD (or Continuous Integration/Continues Delivery).
There are many approaches to do this because it is very depending on your current environments, processes, policies and maybe regulations. It is recommended to conduct an assessment on your current SDLC (software development life cycle) and the IT environments, on top of the DDD exercise, to identify the gaps and to align the solution roadmap with your application migration plan.
orchestration & application definition
You need a container platform to host and run your cloud native applications and to provide the underlying necessity technologies and resources to support your applications.
Ultimately, as one single platform, it should be able to provide ease of use and standardisation of container orchestration, scaling capabilities, resource management, network management, updates and upgrade, standardisation, open standards, application management and definition.
It should also provide seamless integration and experience between the container operation and development process. This is particularly important when come to the consideration to be able to develop, deploy and run your applications with the different application modernisation options that we will be discussing in the next topic.
Application Modernisation Options
We have came this far to have a good understanding of cloud native application is and what is the essential things we need to kick start our cloud native journey. Let’s look at what are the application modernization options we have.
Over the years, your company may have different type of applications for different business operations. The above diagram shows the possible different stage of your applications and what are the modernisation options.
Retain
There are few situations that you may choose to retain your applications as what they are today. These applications are usually still critical to support your business operations and will be left intake to continue to run as it is. These applications could be:
- Applications that may not benefits from cloud native technologies such as auto-scaling and container.
- Applications without source codes but you cannot get rid of them because they are still functional and important to your business operation. The applications are complex and it is not possible to replace or re-implement them but they are well implemented with industry standard integration interfaces that allow other applications or services to communicate with them.
Retire
There maybe some applications already end of life and already in your list to be decommissioned. It is not limited to end of life applications but also could be some of the following situations:
- Applications that no longer required and not being actively used. There is no surprise that you will discover there may be number of applications sit in the datacenter without anyone noticing until we have done a proper housekeeping or assessment.
- Important applications with duplicated features that can be found on other existing applications or services. Through a thorough assessment decision that these applications should be retired and those important features live through the other applications. The reason could be the other applications are more well-documented, well-implemented, implemented with latest framework and etc.
Rehost
Lift and shift your existing applications to package and deploy them as containers. These may includes the following situations:
- Applications that are already implemented with microservice in mind and can be deployed onto your cloud native platform without change or with minimum change.
- Running monolith as container application. As mention earlier, try to minimise monolith container application. The decision to do so is probably it could not be avoided due to specific situation such it is risky to convert them now and may cause major project timeline drifting by doing so. However, these monolith applications should be decomposed into microservice based applications when the dusts have settled.
Replatform
You may have applications that cannot be migrated although you have access to complete documentation and source codes. You can choose to rehost these applications onto virtual machines (VM).
If the applications must be ran and managed together with your container platform, you have option to run these application on Kubvirt – a Kubernetes extension to run virtualised resources as VM on top of Kubernetes platform.
This is different from RETAIN. REHOST is looking at moving applications that are not running in bare metal to VM. It adds additional benefits on top of RETAIN such as by providing hardware utilisation and application consolidation.
One of the possible reason to choose this option is the required technology to run the applications are not available as container yet or the applications required specific native OS libraries to function properly, in addition to looking for hardware utilisation via VM.
Refactor
This option involves intensive rewrite of the existing application functionalities into a brand new microservice-based applications, after all the possible options have been drained out.
Repurchase
Most of the time there will be COTS (commercial off-the-shelf) applications specific for the business domain that simply cannot be replaced with in-house developed applications. These COTs maybe outdated and does not works well with the modernised applications, and need to look at option to purchase other COTS for replacement, or maybe repurchase option outweighs the integration effort and cost.
Summary
We must aware usually there are many applications in one company and there will be many decided migration options for different set of applications.
Regardless of which modernisation options there will be situations that you need to consider what are the options to implement for the supporting services such as workflow, stage management, eventing, integration, security and many more for our microservice applications. These could be introduced as microservice applications or they could be using existing ready solutions in the market. This is another huge discussion area and it is beyond the scope of this article.
With the right expectation and understanding, the next logical step is to perform a proper assessment to uncover the truth of the applications nature and the gaps. With this insights, we can then layout the proper execution plan to modernise our applications.
Remember, application modernisation is not just about the applications but also need to consider the impact of the modernisation exercise to the existing internal costing and budgeting model (if any), governance processes & policies (or SDLC), the supporting services, the operation and application team, and the underlying application platform.