Txture Blog

Cloud Strategy

All articles
Cloud Knowledge

Cloud-Native - the “What”, “Why” and “When”

10min read
2019-10-24
Share this article:
Cloud architect drawing cloud native application architecture

Welcome back to our Cloud Essentials blog post series! In our first installment of this series we talked about the 6 R’s of Cloud Transformation - one of the most widely used concepts in application transformation planning. We learned about six different strategies for the Cloud transformation of enterprise applications and pointed out each strategy’s potentials and risks. If you are currently going through a Cloud transformation but have not read this series’ first article yet, give it a try - it pays off ;-) This time we talk about how to get the most out of the Cloud’s inherent capabilities. We take a closer look at a central concept of application development in the Cloud environment and give you some insights on how we handle it in Txture - let’s talk about Cloud-native.

The WHAT and WHY of Cloud-Native

There has been a buzz lately around Cloud-native applications and platforms like Google’s Anthos and Anthos-Migrate. First of all, let us define our meaning of the term “Cloud-native”. James Bond (not the famous MI6 agent, but a Chief Technologist of Hewlett Packard) describes Cloud-native as follows:

“Cloud-native applications are designed to work with other components and services within a Cloud [...], all working together in what appears to be a single Cloud application or service. Cloud-native applications are developed to be elastic so that they can scale out automatically based on defined workload parameters.[1]"

The Cloud-native approach to application development is the only approach to fully exploit Cloud potentials like scalability, flexibility or manageability. In contrast to conventionally developed, monolithic applications, a Cloud-native application is usually decomposed into small and mutually isolated components - so-called microservices. Each microservice can be deployed independently on a different platform and provides a specific functionality. All microservices communicate through RESTful or RPC-based APIs and together compose the application in its entirety[2]. That fragmentation has many benefits: It makes application development much more flexible since each microservice can be developed, deployed and updated, separately of the application’s other parts.

Furthermore, it simplifies the coordination and collaboration in the development department. At Txture we have small dev-teams that contribute to each microservice - for example, our Application Transformation Cockpit. These teams work autonomously without being restricted by input and timing of the other teams. Our products are developed in small steps using short iterations. Feature requests can be quickly met by allowing teams to independently handle development and integration. This way we can avoid release-cycles and steadily develop our products through small increments. This procedure, which is also known as continuous delivery, plays a prominent role in Cloud-native development and increases agility. Moreover, a Cloud-native strategy allows high flexibility in operation since each microservice can also be handled and maintained separately.

Practical examples and experience

The Cloud Native Computing Foundation offers a collection of use case studies. If you are interested in some real-world examples, I recommend taking a look at the CNCF’s website. You may read about, how successful enterprises report about their challenges and successes while implementing their cloud-native strategy.

For case studies visit cncf.io

Microservices are packed as containers which enable horizontal scaling and make the services portable to other container engines. Each container can be easily scaled-out or scaled-in to ensure a cost-optimized utilization of the Cloud infrastructure or to run peak performance levels.

For managing a set of containers, container-orchestration is used. A widely used tool for orchestration is the open-source platform Kubernetes that has gained a lot of mainstream adoption lately Kubernetes automatically deploys new instances of microservices in containers, scales and manages existing ones according to policies. Moreover, the orchestration enables easy load balancing and thus contributes towards an optimized utilization of each container.

Central Cloud-native aspectsCentral Cloud-native aspects

The WHEN/WHEN NOT To Go Towards Cloud-Native

Now that we know the most important characteristics of a Cloud-native strategy we have to consider when it is and when it is not smart to implement applications in a Cloud-native style.

WHEN
For our development at Txture rapid time-to-market and easy adaptability play a decisive role. Cloud-native gives us the flexibility to quickly advance our product and adapt it to our customers’ and partners’ requirements. Many developers also appreciate the reduced risk (resiliency) in product development, which results from the fact that delaying obstacles during the development process can be isolated to the respective microservice.
Above these reasons, a Cloud-native strategy may be your approach in deploying and operating your large-scale enterprise IT. Cloud-native applications offer a high potential regarding performance, efficiency and scalability when done right[3]. If you rely on auto-scaling or load-balancing capabilities, you want to optimally utilize your Cloud platform’s underlying resources and IT agility is important for you, then this is the right strategy. So, if you want to build your applications entirely on a Cloud architecture, Cloud-native may be your best option.

WHEN NOT
However, there are several situations where it is not recommended to go towards Cloud-native: Transforming applications towards Cloud-native can be costly and time-consuming. Often it’s necessary to re-architect an application. When deciding for or against a Cloud-native strategy, the cost-benefit ratio should always be estimated. Applications with low functional and business significance or applications that will retire soon, typically shouldn’t be considered for a large refactoring.
Moreover, if you are forced to "cloudify" your IT portfolio due to external factors but do not have the time and resources to re-architect your applications properly, a Cloud-first strategy might be your better option. In essence Txture’s Cloud readiness assessment helps you to make this decision for each of your applications.

I hope you enjoyed the second installment of our Cloud Essentials series! Please get in touch with me to discuss any Cloud transformation topic or find out more about how the Txture platform can help you with your Cloud Transformation.

Florian Wirthensohn
Author
Florian Wirthensohn
Florian is an IT Transformation Consultant and Analyst at Txture. Besides his daily activities in pushing forward the customers’ Cloud Transformation, Florian is passionate about researching promising topics around the future of IT. In addition to Cloud Transformations, Florian also specializes in Enterprise Architecture Management and IT Infrastructure Management.

References

[1]
Bond, J. (2015): The Enterprise Cloud - Best Practices for Transforming Legacy IT. Sebastopol, CA, O’Reilly.
[2]
Balalaie, A., Heydarnoori, A., Jamshidi, P. (2016): Microservices Architecture Enables DevOps. IEEE Computer Society.