The Road to Cloud Native Applications

The IT landscape in a modern enterprise looks more fragmented than ever. Mainframes that were implemented decades ago still perform mission critical operations, and they sit hand in hand with heavily customised commercial-off-the-shelf and bespoke Java or .Net applications. Throw into the mix some smaller apps built in newer programming languages by some eager developers - and you have an IT environment on premise which gets harder and harder to manage.

Let's have a closer look at a typical bespoke application: most of them contain all functionality in a single block, such as user interfaces, business processes, integration services and APIs - all running on a classic J2EE application server that has grown into a monolith over the past 10-15 years and costs the organisation large licence costs every year.

Many organisations are now looking at moving some of these business applications into a cloud environment - many of them as part of a managed service that is operated by cloud providers. They envisage to run their apps in a more agile and efficient manner, make use of the cloud providers' on-demand compute capacity and administrative functions, and integrate them more seamlessly with already existing SaaS applications.

The challenge, however, is 1.) the complexity of the existing monolithic applications where functions are not loosely coupled, but heavily interdependent and 2.) the fact that the existing underlying application servers do not only contain the application itself, but also a myriad of administrative and operational features that are mixed with core application functions. What sense would it make to migrate that same application server into the cloud where operational features for lifecycle, deployments and configurations are already in place ?

That's where we introduce the concept of the "Cloud Native Applications".

A Cloud Native Application is

• designed for a hybrid cloud deployment; it means it can run either in the cloud or on premise providing the same functionality.
• built on a modular microservices based architecture instead of a single block with many interdependent functions.
• fostering collaboration between developers and administrators using a DevOps approach.
• using automation tools to roll out changes to the application; something that becomes more and more critical once microservices based application move to the cloud.
• deployed on a container platform to make use of the elasticity and flexibility of microservices

Cloud Native Applications are not only newly built apps using modern programming languages, but can also be existing monolithic applications running on legacy application servers that an organisation want to migrate to a cloud platform.

So what are the steps that organisation need to take into account when embarking on that journey ?

First, have a look at the platform.

A cloud native application should run on a lightweight application server that can easily be migrated onto a cloud platform. A large scale complex legacy application server is less suitable for these workloads since it contains too many operational and administrative features. Once running on a modern application server, you should consider deploying your application physically on a container platform. 

Containers are smaller and more lightweight than virtual machines given the underlying operating system is abstracted. Leading Container Platforms such as Red Hat OpenShift also provide supporting capabilities to run your cloud native applications, such as service discovery, functions for build and deploy automation, and provisions for service routing and load balancing. Organisations can deploy their applications on a container platform using out-of-the-box images for an application server, thereby enabling them to migrate them completely onto the cloud.

In a second step, look at the application itself and its functions.

In order to run your application as a cloud native app it is recommended to break out each of the functions into microservices with their own runtime so they can be managed and deployed independently. Follow microservices best practices by defining the correct boundaries around these services. Also, address the organisational impact by assigning the responsibility for the lifecycle and the deployment of a microservice to a dedicated team of about 6-8 people.

In a third step you would deploy that refactored cloud native app onto your container platform, making use of innovative microservices technologies such as service discovery and circuit breakers, as well as automation technologies to roll out code changes to your cloud native application and deploy them across your Open Hybrid Cloud platform.

As a result, you can make full use of your cloud platform's native infrastructure functions. Also, you will be able to react quicker to your end customers' requirements and roll out changes to your microservices in hours or days instead of weeks and months.

Feel free to talk to me about how Red Hat can assist you on your journey to Cloud Native Applications.

Daniel Soffner

Senior Solution Architect, Cloud and Emerging Technologies

Red Hat Australia, Melbourne