Cloud-Native Applications in Java

This lesson looks at the essential elements of building your first cloud-native application.

We will do the minimal number of steps required to get a microservice running in our development environment. If you are an experienced Java developer using IDEs such as Eclipse, you will find yourself on familiar turf. Though most of it will be like building traditional applications, there are a few nuances, which we will discuss in this lesson and summarize at the end.

For any profession, the tools are very important, and that applies to coding as well. Before writing a line of code, we need to get the right equipment to start. Let us learn more about it with the following topics:

• Getting an IDE

• Setting up Internet Connectivity

Professional software writing goes through various stages. In the following sections, we will talk about all the various stages we will follow while developing the application. Let us learn more about it with the following topics:

• Requirements/User Stories

• Architecture

• Design

• Testing and Development

• Building and Deployment

Having looked at the basics, let's write our product service. After IDE setup, the next step is to select a framework to write the service. Let us learn more about it with the following topics:

• Dropwizard

• Vert.x

• Spring Boot

In this video we will learn how to write a product service.

We have just developed a basic service with two APIs that respond to requests. Let's add a few capabilities that will enable to it to be a good cloud citizen.

Why is service registration and discovery important? So far, we have been calling the service through its URL, which includes the IP address—for example, http://localhost:8080/prod—thus we expect the service to run at that address. Even though we might substitute the test and the production URLs, the step of calling the service at an IP address and port is still static.

The product service boots up and listens on port 8081 for product service requests. We will now add the necessary instructions so that the service instance registers itself with the Eureka registry. Thanks to Spring Boot, we only must do a few configurations and annotations. Let us learn more about it with the following topics:

• Creating a Product Client

• Seeing the Lookup in Action

Summarize your learning from this lesson.

In this lesson, we pause application development and take a step back to look at the bigger picture of designing cloud applications. As seen in the first chapter, applications in the cloud have more unique challenges than the traditional enterprise applications that we have been developing so far. Also, the business requirement of agility must be met by not compromising on performance, stability, and resiliency. Hence, a look at the first principles becomes important.

The web has made HTTP tremendously popular and is the de facto integration mechanism for accessing content on the internet. Interestingly, this technology was not hugely popular within applications that relied on native and binary protocols, such as RMI and CORBA for inter-application access.

An Application Programming Interface (API) provides a standard interface or contract to consume its services over the internet. The API defines the structure of the input and output and remains constant over the life of an API version. Let us learn more about it with the following topics:

• Role of API Gateways

• Benefits of an API Gateway

The traditional model of application development, where all the features and functionalities were bundled in a large package called a monolithic application, is becoming less popular for multiple reasons. Monolith applications take on too many responsibilities in the form of function and logic. It is this characteristic which leaves them with high coupling and low cohesion. The reuse factor in monoliths tends to be low since one part of the functionality cannot be separated from the rest of the function and logic. Let us learn more about it with the following topics:

• Bounded Context/Domain-driven Design

• Classification into Up/Downstream Services

The name microservice does not necessarily mean that the service must be small. Let us learn more about it with the following topics:

• Differences Between Microservices and Service-Oriented Architecture (SOA)

• Service Granularity

The whole notion of microservices is about the separation of concerns. This requires a logical and architectural separation between the services with different responsibilities.

As you start designing the applications, you need to be aware of the various service design and integration patterns. The microservice design patterns can be categorized into multiple categories depending upon the problem being solved. The most common categories and the relevant patterns are discussed in the following videos. Let us learn more about it with the following topics:

• Content Aggregation Patterns

• Aggregation by Client

• API Aggregation

• Microservice Aggregation

• Database Aggregation

• Coordination Models

Although development might be in a microservice style (separate code base for services, different teams working on different services), the deployment essentially follows the monolith style. Let us learn more about it with the following topics:

• Service per WAR/EAR

• Service per Process

• Service per Docker Container

• Service per VM

• Release Patterns

One of the key design philosophies of microservices is the bounded context and the service(s) managing the data store. Within a bounded context, multiple services might have access to a common data store or adopt a per service data store paradigm. Since there are potentially multiple instances of a service running, how do we make sure the data read/update operations do not lead to a deadlock in resources? Let us learn more about it with the following topics:

• Command Query Responsibility Segregation (CQRS)

• Duplicating Data

• Fit for Purpose

With the proliferation of microservices, the challenges of managing security for these services becomes a challenge.

Summarize your learning from this lesson.

Having understood the design principles, let's take the skeleton services developed in Lesson 2, Writing Your First Cloud-Native Application, and do some real work on them to make them production-ready.

Let's take our product project developed in Chapter 2, Writing Your First Cloud-Native Application, forward. We will incrementally enhance it while discussing the concepts. Let us learn more about it with the following topics:

Simple Product Table

Running the Service

In this video we will learn about the limitations of traditional databases. Let us learn more about it with the following topics:

• Local Cache

• Distributed Cache

A distributed cache is one way to solve the scaling problem. However, it introduces certain challenges, such as cache staleness (keeping the cache in sync with the database) and additional memory requirements. Also, caching is the beginning of the transition to the CQRS paradigm. Revisit the concepts of CQRS that we discussed in Lesson 3, Designing Your Cloud-Native Application. Let us learn more about it with the following topics:

• Elasticsearch and a Document Database

• Why Not Use Only a Document Database or Elasticsearch?

• Getting MongoDB Ready with Test Data

• Splitting the Services

• Getting Elasticsearch Ready with Test Data

So far, we have looked at getting the data. Let's look at some of the data modification operations, such as creating, updating, and deleting (CRUD operations). Given the popularity of REST for cloud-based API operations, we will do our data manipulation through REST methods. Let's pick the HSQLDB example with Hazelcast that we worked on previously in this lesson. Let us learn more about it with the following topics:

• REST Conventions

• Inserting a Product

• Updating a Product

• Deleting a Product

If you do a get operation that populates the cache, then either the cache updates, or invalidation must take place when PUT/POST/DELETE operations occur that update the data. Let us learn more about it with the following topics:

• Validations and Error Messages

• Format Validations

• Data Validations

• Business Validations

In case of error, the simplest thing to begin with is to indicate an error message telling us what went wrong, especially in case of a bad input request or business validations since the client (or requestor) may have no idea of what went wrong. For example, in the preceding case, the NOT_FOUND status code is returned, but no other details are supplied. Let us learn more about it with the following topics:

• Starting ActiveMQ

• Golden Source Update

• Service Methods

• Raising an Event on Data Updates

In this video we will learn how to use spring JMST template to send a message. Let us learn more about it with the following topics:

• Insert, Update, and Delete Methods

• Testing the CQRS Update Scenario End-to-End

Summarize your learning from this lesson.

In this lesson, we take a deep dive into testing cloud-native applications. Testing has matured a lot from manual testing to automated testing, using various testing tools, strategies, and patterns. The benefit of this approach is that the testing can be done frequently in a failsafe fashion that is important for cloud development.

In this course, we started developing a simple service in Chapter 2, Writing Your First Cloud-Native Application, in Spring Boot to get you excited about cloud development. However, real development follows a different style of best practice. Let us learn more about it with the following topics:

• Test Driven Development

• Business Driven Development

Testing large internet applications for the cloud requires a disciplined approach where a few patterns come in handy. Let us learn more about it with the following topics:

• A/B Testing

• Test Doubles

• Test Stubs

• Mock Objects

The various types of testing we discuss later in the lesson were already known even before cloud computing became popular. The principles of Agile development using continuous integration (CI) and continuous development (CD) make it important to automate these types of testing so that they are executed each time a code check-in and build happens.

Let's apply the testing principles we learned to the Product service that we have been building so far. We start from a user point of view and hence with acceptance testing. Let us learn more about it with the following topics:

• BDD Through Cucumber

• How Does Cucumber Work?

• Spring Boot Test

• Integrating JaCoCo

Summarize your learning from this lesson.

In this lesson, we will dive into the deployment model for the microservice—including how to package your application as a Docker container, how to set up the CI/CD pipeline, and how to protect your service from security attacks such as a distributed denial of service (DDoS).

In this video, we will cover the deployment models that will be used to deploy our application in the cloud environment. Let us learn more about it with the following topics:

• Virtualization

• Containers

• Eureka Server

• Product API

To connect the product API to an external database instead of an in-memory database, first create a container image with the data already populated in it.

Having covered the packaging and deployment models of cloud-native applications, we will now cover the patterns used for deploying cloud-native applications. Traditionally, applications get deployed in several environments such as development, testing, staging, pre-production, and so on, and each of these environments might be a scaled-down version of the final production environment. Applications move through a series of pre-production environments and get deployed finally to the production environment. However, one significant difference is that while downtime is tolerated in all other environments, downtime in a production deployment could lead to serious business consequences. Let us learn more about it with the following topics:

• Blue-Green Deployment

• Canary Deployment

• Applying CI/CD to Automate

Summarize your learning from this lesson.

Having developed, tested, and deployed the applications using a deployment pipeline such as Jenkins, in this lesson, we will look at the runtime ecosystems in which our applications or services run.

Running many services at scale in production is not easy. As more services are released in production, their management starts getting complex. Hence, this video talks about recap of the problems, discussed in the microservices ecosystem and solved in some code samples in a previous lesson.

In this topic we will learn how to implement runtime reference architecture. Let us learn more about it with the following topics:

• The Server Part of the Config Server

• The Config Client

In this video we will learn how to refresh the properties. Let us learn more about it with the following topics:

• The Microservice Frontend

• Netflix Zuul

So far, we have been individually deploying the services such as Eureka, the config server, the product service, and Zuul. Recollecting from the previous lesson, we can automate their deployment through CI, such as Jenkins. We also saw how the deployment could be done with Docker containers. Let us learn more about it with the following topics:

• Kubernetes Architecture and Services

• Minikube

• Running Product Service in Kubernetes

Another popular runtime for cloud-native applications is to use a PaaS platform, specifically, application PaaS platforms. PaaS provides an easy way to deploy cloud-native applications. They provide additional services like file storage, encryption, key-value storage, and databases which can be easily bound to the applications. PaaS platforms also provide an easy mechanism to scale cloud-native applications. Let's now understand why PaaS platforms provide an excellent runtime for cloud-native applications.

Let's create a simplified version of the product service that just connects to a MySQL service that we created earlier to run queries.

Summarize your learning from this lesson.

In this lesson, we will cover some of the deployment options available in the Amazon AWS platform. The AWS platform is one of the oldest and most mature of the cloud service providers. It was introduced in 2002 and has been a leader in the space since then. AWS has also been constantly innovating and has introduced several new services that have found wide adoption among a broad variety of customers, from single person start-ups to, enterprises.

Amazon AWS was the pioneer of cloud computing and has been expanding its cloud offerings ever since to maintain its leadership position.

Of the various services offered by the AWS platform, we will be focusing this chapter on covering some deployment options specifically targeted for the kind of web APIs that we have been using as an example. Let us learn more about it with the following topics:

• Deploying a Runnable JAR

• Deploying Docker Containers

• Deploying Spring Boot App to the Elastic Container Service

The AWS Lambda service allows the deployment of simple functions to be invoked on event triggers.

Summarize your learning from this lesson.

This lesson discusses application design and deployment for Azure—a Microsoft public cloud platform. The essence of cloud-native development is the ability to integrate your application with PaaS platforms provided by the cloud provider. You, as a developer, focus on creating value (solving customer problems), and allow the cloud provider to do the heavy lifting for your application's infrastructure

Azure provides an ever-increasing set of PaaS and IaaS across a spectrum of technology areas. For our purpose, we will look at the subset of areas and services that are directly applicable and used by our application.

As we saw in the previous topic, Azure provides several options to build and deploy applications on the platform. We will use our example of the product API REST service to examine the various options provided by Azure to deploy and run our application. Let us learn more about it with the following topics:

• Deploying Spring Boot API to Azure App Service

• Deploying Docker Containers to Azure Container Service

Summarize your learning from this lesson.

This lesson discusses various types of Anything as a Service (XaaS), which includes Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Integration Platform as a Service (iPaaS), and Database as a service (DBaaS), and everything you need to factor in when exposing infrastructure or platform elements as services. In cloud-native mode, your application might be integrating with social media APIs or PaaS APIs, or you could be hosting services that will be used by other applications. This lesson covers the concerns you need to deal with when building your own XaaS model.

Cloud computing has pioneered the distribution model for elastic, pay-as-you-go, on-demand IT hosted services. Any part of the IT delivered as a service is loosely covered under the broad theme of cloud computing. Within the cloud computing theme, depending on the type of IT service, there are various terms for specific services of the cloud. Most of the terms are different variations of the term XaaS, where X is a placeholder that can be changed to represent multiple things.

Let's review the key design concerns that need to be addressed when building XaaS and providing those services for consumption.

In the previous topic, we saw the design concerns when building your own service provider. In this topic, we will see how, if you are trying to build a consumer application, to take advantage of the REST services provided by third-party companies.

Summarize your learning from this lesson.