days
0
-55
-3
hours
0
-9
minutes
-4
-9
seconds
-5
-4
search
Exploring key requirements

The four key requirements for building cloud-native apps

Erica Langhi
cloud
© Shutterstock / yingko

“Cloud-native” apps are designed to take advantage of a distributed systems environment, increasing the applications’ performance, scalability and fault tolerance. In this article, Erica Langhi will share insight into the key requirements for making your app development approach fully “cloud-native”.

Despite all the conversations around it, many aren’t yet aware that a cloud-native approach to app development is about more than just running an app on AWS or Azure. Rather, a fully cloud-native approach to app development translates to a specific set of practices in your architecture, technology, and culture.

In this article, Erica will share insight into the key requirements for making your app development approach fully “cloud-native”:

  1. DevOps automation
  2. Service-based architecture
  3. API-based communications
  4. Containers and orchestration

SEE ALSO: Cloud Native Communication: Using Ambassador and Consul Connect with Java Apps

The four key requirements for building cloud-native apps

The cloud-native model for application development sees developers build apps that fully leverage the strengths of cloud computing, with the intent of building flexible, scalable and fault-tolerant apps – which can be deployed in any environment.

However, to fully embrace the cloud-native model across your organisation requires adopting the following set of practices: a DevOps culture, a service-based architecture, API-based communications, and containerisation.

Cultivating DevOps

A DevOps culture exists where the processes of an organisation’s development and operations teams have been unified, which in turn means that many interdepartmental tasks can be automated.

A DevOps culture sees developers and operations teams committed to a shared understanding and responsibility for their work, which results in a far more integrated approach to creating and deploying applications. This is essential for a cloud-native development model where the most productive workflow involves making regular, iterative updates to an application, requiring clear lines of communication between the developers responsible for writing the code, and the operations teams responsible for implementing it.

DevOps takes time and effort to implement, but IT leaders know that the long-term benefit of making the transition far outweighs the initial setup challenges. The transformation inevitably takes time, but once complete, the result is shorter development times, and applications that are more flexible for your organisation.

Creating a service-based architecture

Another key part of cloud-native development is adopting a service-based architecture, which sees the functions of applications broken down into independent modules, which are the eponymous “services”.

There are various ways a team can go about the transition to a service-based architecture. One popular path is through adopting a microservices architecture, which breaks applications down into their smallest parts, independently of one another.

Most microservices success stories involve an existing monolith being broken down into a microservices architecture. Analysing the existing monolith can help developers see how the components of an application work together, which helps inform where the boundaries of microservices should be.

Those existing monolithic applications cannot simply be discarded, since many of them have been dutifully and efficiently running a function within an organisation for many years. The focus should instead turn to implementing cloud-native principles upon these applications, and to encourage the gradual and iterative breaking down of these monolithic applications into microservices.

API-driven interfaces

Which introduces us to the third requirement in any cloud-native app development model: API-driven interfaces. This sees a widespread adoption of application programming interfaces (APIs) to be offered to internal and external clients and users, which can be consumed via clean and contracts within a network. APIs and API Gateways work alongside service meshes, focused on managing internal service-to-service communication.

SEE ALSO: Open standards can make or break a Kubernetes implementation

Orchestrating containers

When adopting a service and task-based architecture which needs to scale on demand, the natural choice is to realise this vision through containers. Containers allow applications to become environment-agnostic, and also help to eliminate application conflicts between the developer and operations’ teams, which improves productivity.

To get these containers to talk and interact with one another, however, you’ll need orchestration to be in place. This is where Kubernetes frequently comes into the picture.

We often simplify Kubernetes and describe it as a framework that runs containers. However, it’s more accurate to say that Kubernetes is a platform that can run distributed containers resiliently, taking care of scaling and failover needs and different deployment patterns. Kubernetes comes with a bundle of APIs especially designed with the developer in mind, dividing resources among containers. For a complete cloud native experience, Kubernetes needs to be complemented by tools which handle container networking, monitoring, and storage, along with many other tasks.

Keeping the transition incremental

The key to successfully transitioning to a cloud-native app development model is a step by step approach.

Begin by making sure your team is transitioning towards a DevOps culture, and then start the technical work by slowly migrating monoliths and applications to the cloud. As this happens, you can begin to understand which workloads can be containerised and establish container orchestration. Once you get running on a cloud platform, you can then start to take further advantage of other cloud services like cloud native API management and pipeline automation.

After that, it’s a matter of constant iteration – both in your team’s education and comfort level, and in the state of your application. Eventually, your patience will be rewarded with an extremely robust and adaptive application that can quickly pivot to whatever organisational needs you face.

Author
Erica Langhi
Erica Langhi is a Senior Solution Architect EMEA at Red Hat, where she helps customers understand how Red Hat's technologies can provide real value and help solve their business problems. She has over 20 years' experience and specialises in data integration and open source software.

guest
0 Comments
Inline Feedbacks
View all comments