What do you get with eBook?

Instant access to your Digital eBook purchase

Download this book in EPUB and PDF formats

Access this title in our online reader with advanced features

DRM FREE - Read whenever, wherever and however you want

Buy Now

Cloud-Native Applications in Java

Chapter 1. Introduction to Cloud-Native

The advent of cloud computing and the ubiquity of mobile devices have led to the rise of consumer-facing companies (such as Amazon, Netflix, Uber, Google, and Airbnb) that have redefined the entire customer experience. These companies have built their applications (both web and mobile interfaces) on the cloud, using features or services that allow them to scale up or down based on demand, be available at all times, and be ready to handle failures at all levels.

Traditional enterprises are looking at these consumer-facing companies and want to adopt some of their best practices. They do this to help scale up their rapidly evolving enterprise applications, allowing them to take advantage of the elasticity and scalability of the cloud.

Before we dive deep into cloud-native, let's see what this chapter holds. We will cover the following topics in this chapter:

Why go cloud-native?
What is cloud-native?
Intro to the 12-factor app
Why move from monolithic applications to distributed microservice-based applications?
The advantages of building a distributed microservice-based application

Why go cloud-native?

Let's have a look at the following points to understand why we need to go cloud-native:

The first wave of cloud adoption was about cost savings and business agility (especially around infrastructure provisioning and cheap storage). With increasing cloud adoption, enterprises started discovering Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) services and their utilization in building applications that leverage the elasticity and scalability of the cloud, all the while embracing the inherent failures of the cloud platform.
A lot of enterprises are adopting greenfield design and development of microservices in the area of digital initiatives. When dealing with the Internet of Things (IoT), mobile devices, SaaS integration, and online business models, enterprises are working with niche players in the market. These new age business models are being designed and developed as a system of innovation on the enterprise end. The models are iterated rapidly to identify and bubble up the customer's needs, their preferences, what works, and what does not work.
Enterprises are also developing digital services based on their product lines. The products are enhanced with IoT to enable them to emit data about the products' performance. The data is collated and analyzed for patterns such as predictive maintenance, usage models, and external factors. The data from customers is collated and aggregated to build newer models for product enhancements and new features. A lot of these new digital services use the cloud-native model.
These modern digital solutions use APIs from various providers, such as Google Maps for location, Facebook/Google for authentication, and Facebook/Twitter for social collaborations. Mashing all these APIs with the features and functionality of enterprise business allows them to build a unique proposition for the customer. All of this integration is happening at the API level. The mobile application is not meant for tens of hundreds of users, but tens of millions of users. This means that, as the load increases, the underlying application functionality should be able to scale up to provide a seamless experience to the customer.
One way to scale up the resources for the enterprise is to do the heavy lifting in terms of service/environment provisioning as the load goes up or in case of failures. Another way is to offload the heavy lifting of the underlying services to the cloud platform provider. This is the sweet spot where building cloud-native applications that make use of the cloud provider's platform services allows the enterprise to offload the key aspects of scalability and focus on value generation parts.

What is cloud-native?

When applications are designed and architected to take advantage of the underlying IaaS and PaaS services supported by the cloud computing platform, they are called cloud-native applications.

This means building reliable system applications, such as five nines (99.999%), that run on a three nines (99.9%) infrastructure and application components. We need to design our application components to deal with failures. To handle such failures, we need a structured approach for scalability and availability. To support the entire scale of applications, all the pieces need to be automated.

Cloud adoption typically happens in a series of steps, where the enterprise starts exploring the services before they start building cloud-native applications. The adoption starts with the movement of Dev/Test environments to the cloud, where rapid provisioning is the key ask from the business and developer community. Once the enterprise is past the environment provisioning stage, the next step/models in which the enterprise applications are migrated to the cloud-native model will be discussed in the following sections.

Lift and shift

Traditionally, enterprises started on their cloud computing journey with IaaS services. They did a lift and shift of the business application workloads from on-premises data centers and moved to the equivalent rented capacity on the cloud computing platform. This is the first wave of adoption of cloud computing platforms, where enterprises are shifted from a capital expenditure model to an operating expenditure model.

IaaS, as the names suggests, is focused on infrastructure—compute nodes, network, and storage. In this model, enterprises can take advantage of the elasticity of the cloud, where compute nodes can be added or removed based on the incoming demand or load. The virtual machine (VM) abstracts out the underlying hardware and provides the ability to scale the number of VMs up or down with just a few clicks.

Enterprises typically make use of IaaS in the first wave because of the following:

Variability of resources: The ability to add/remove resources at will, which in turn allows more business agility
Utility model: IaaS provides basic resources that are rented out on an hourly basis, allowing more predictability and an opex model

Going native

Once the enterprises start becoming comfortable with the IaaS, the next wave of adoption comes in terms of adoption of PaaS as part of the application workloads. In this stage, the enterprises start discovering services with the following benefits:

Platform services replacement: This involves the identification of potential platform features of the enterprise, lifting and shifting the workload, and replacing it with equivalent platform services from the cloud provider. For example:
- Replacing application messaging systems with queuing systems provided by the cloud provider (such as AWS SQS)
- Replacing data stores or relational database management systems (RDMBS) with equivalent managed data services (such as AWS RDS)
- Replacing security or directory services with a managed directory or security services (such as AWS Directory and AWS IAM)
- These services allow the enterprise to do away with all the operational efforts, such as data store backup, availability, scalability, and redundancy, and replace them with a managed service that provides all these features

Application services replacement: Enterprises discover new services that can replace their own platform or utility services. For example:
- Replacing build and release services or products with equivalent DevOps services from the cloud provider (such as AWS CodePipeline, AWS CodeCommit, or AWS CodeDeploy)
- Replacing application services or products with equivalent application platform services (such as AWS API Gateway, AWS SWF, and AWS SES)
- Replacing analytics workload services with equivalent application analytics services (such as AWS Data Pipeline and AWS EMR)

Once the applications start adopting the platform services, the applications start abstracting out features or functionalities provided by commercial off-the-shelf (COTS) products (such as messaging, notification, security, workflow, and API Gateway) and replacing them with equivalent feature platform services. For example, instead of hosting and running the messaging IaaS, movement to an equivalent platform service means moving to a model where you pay only for the number of messages sent, without incurring any additional operational costs. This model brings significant savings, as you move from renting and operating the product to a model where the product is rented only for the time it is utilized.

Going serverless

Once the enterprise has adopted the PaaS to build the application, the next step is to abstract out the application logic as a series of smaller functions and deploy them. These functions are invoked as a reaction to an event from the user or agent, which results in these functions computing the incoming events and giving a result back. This is the highest level of abstraction, where the application has been divided into a series of functions and these functions are deployed independently of each other. The functions communicate with each other using asynchronous communication models. Cloud computing platforms provide features such as AWS Lambda and Azure Functions for going serverless.

Cloud-native and microservices

To enable the adoption of the IaaS and PaaS services, a change in how the applications are designed and architected needs to be made.

The model of designing enterprise applications on a base platform (read: application server) meant that the heavy lifting of the application's scalability and availability was the responsibility of the platform. Enterprise developers would focus on using the standardized JEE patterns and developing components (Presentation, Business, Data, and Integration) to build fully functional and transactional applications. The extent to which the application could be scaled was limited by the abilities (node clustering and distributed caching) of the underlying platform:

Monolithic application

A business application built as a monolithic application is typically characterized by the following factors:

The entire application logic is packaged into a single EAR file
The application reuse is derived by sharing JARs
Application changes are planned months in advance, typically in a big push once a quarter
There is one database that encompasses the entire schema for the application
There are thousands of test cases that signify the amount of regression
The application design, development, and deployment requires coordination among multiple teams and significant management

With the advent of social interactions and mobile users, the scale of application users and data started increasing exponentially. Enterprises soon found that the platform was becoming a bottleneck in terms of the following issues:

Business agility: The operational cost of managing the application platform and making constant changes to the features/functionalities was getting hampered because of the monolithic nature of the application. Even for a small feature change, the entire cycle of regression tests and deployment across server clusters was eating into the overall speed of innovation. The mobile revolution meant that the problem was not just at the channel layers, but also percolated down to the integration and systems of record layers. Unless enterprises fixed the problem across these layers, the ability to innovate and be competitive in the market would be under threat.
Cost: To handle the increased demand, the IT Operations team were adding new server instances to handle the load. However, with each new instance, the complexity was increasing along with license costs (that depended on the number of cores). Unlike the Facebooks of the world, enterprise cost per user was increasing with every user acquisition.

At this time, enterprises started looking at open source products and how modern applications are getting built in consumer-facing companies serving millions of users, handling petabytes of data, and deploying to the cloud.

Consumer-facing companies encounter these hurdles early in their life cycle. Lots of innovation led to the design and development of new open source products, as well as design patterns for cloud computing.

In this context, the whole premise of service-oriented architecture (SOA) was looked at and enterprises investigated how the application architecture could adopt principles of designing autonomous services that are isolated, discrete, and could be integrated and composed with other services. This has led to the rise of the microservices model, which adapts and integrates very well with the cloud services model, where everything is available as a service and as an HTTP endpoint.

Microservices is a specialization of and implementation approach for service-oriented architectures (SOA) used to build flexible, independently deployable software systems

– Wikipedia

Microservices are designed and developed, keeping in mind that a business application can be built by composing these services. The microservices are designed around the following principles:

Single-responsibility principle: Each microservice implements only one business responsibility from the bounded domain context. From a software point of view, the system needs to be decomposed into multiple components where each component becomes a microservice. Microservices have to be lightweight, in order to facilitate smaller memory footprints and faster startup times.
Share nothing: Microservices are autonomous, self-contained, stateless, and manage the service state (memory/storage) through container-based encapsulation models. The private data is managed by a service and there is no contention on the data from any other service. Stateless microservices scale better and start faster than stateful ones, as there is no state to be backed up on shutdown or activated on startup.
Reactive: This is applicable for microservices with concurrent loads or longer response times. Asynchronous communication and the callback model allow optimal utilization of the resources, resulting in better availability and increased throughput of the microservices.
Externalized configuration: This externalizes the configurations in the config server, so that it can be maintained in hierarchical structure, per environment.
Consistent: Services should be written in a consistent style, as per the coding standards and naming convention guidelines.
Resilient: Services should handle exceptions arising from technical reasons (connectivity and runtime), and business reasons (invalid inputs) and not crash. Patterns, such as circuit breakers and bulk headers, help isolate and contain failures.
Good citizens: Microservices should report their usage statistics, the number of times they are accessed, their average response time, and so on through the JMX API or the HTTP API.
Versioned: Microservices may need to support multiple versions for different clients, until all clients migrate to higher versions. There should be a clear version strategy in terms of supporting new features and bug fixing.
Independent deployment: Each of the microservices should be independently deployable, without compromising the integrity of the application:

Moving from a monolithic to a microservices-based application

The microservices' design, development, and deployment considerations are covered in detail in the subsequent chapters. We will see how to build services for an e-commerce product. I am sure everyone is quite familiar with e-commerce and will understand the product requirements easily.

Description

Businesses today are evolving so rapidly that they are resorting to the elasticity of the cloud to provide a platform to build and deploy their highly scalable applications. This means developers now are faced with the challenge of building build applications that are native to the cloud. For this, they need to be aware of the environment, tools, and resources they’re coding against. If you’re a Java developer who wants to build secure, resilient, robust, and scalable applications that are targeted for cloud-based deployment, this is the book for you. It will be your one stop guide to building cloud-native applications in Java Spring that are hosted in On-prem or cloud providers - AWS and Azure The book begins by explaining the driving factors for cloud adoption and shows you how cloud deployment is different from regular application deployment on a standard data centre. You will learn about design patterns specific to applications running in the cloud and find out how you can build a microservice in Java Spring using REST APIs You will then take a deep dive into the lifecycle of building, testing, and deploying applications with maximum automation to reduce the deployment cycle time. Gradually, you will move on to configuring the AWS and Azure platforms and working with their APIs to deploy your application. Finally, you’ll take a look at API design concerns and their best practices. You’ll also learn how to migrate an existing monolithic application into distributed cloud native applications. By the end, you will understand how to build and monitor a scalable, resilient, and robust cloud native application that is always available and fault tolerant.

What you will learn

[*] See the benefits of the cloud environment when it comes to variability, provisioning, and tooling support [*] Understand the architecture patterns and considerations when developing on the cloud [*] Find out how to perform cloud-native techniques/patterns for request routing, RESTful service creation, Event Sourcing, and more [*] Create Docker containers for microservices and set up continuous integration using Jenkins [*] Monitor and troubleshoot an application deployed in the cloud environment [*] Explore tools such as Docker and Kubernetes for containerization and the ELK stack for log aggregation and visualization [*] Use AWS and Azure specific tools to design, develop, deploy, and manage applications [*] Migrate from monolithic architectures to a cloud native deployment

What do you get with eBook?