Starting with Cloud-Native applications

Four years ago I wrote a “Docker learning path” so people could easily learn how to take baby steps toward Kubernetes. Essentially the steps are: 1 - learn docker, 2 - learn docker-compose , 3 - learn Docker Swarm (Today I would suggest skipping this step), and 4 - learn Kubernetes.

While that post had focused on suggesting a learning path for people to adopt containers, this blog post is focused on suggesting a learning path for developers to produce cloud native applications.

In the last years, backend developers are interested in producing cloud-native applications, but still many of them don’t know where to start. Because I’ve been talking in conferences, recording videos, writing a book about microservices and cloud-native applications, people come to me asking “Where should I start?”. So I decided to write this blog post to help those developers. Here is my suggestion of baby steps, no matter what language you are using.

Baby steps toward Cloud Native applications

These steps assume two applications (two microservices) that will communicate with each other, and handle the most common scenarios in a cloud native environment. The expected result will be a microservice A calling a microservice B. You’re encouraged to implement the uses cases bellow to gain the expertise needed to create cloud-native applications.

• Use your favorite language to create a microservice B with some REST endpoints to perform CRUD operations.

  Suggested read: CRUD and REST

• Document your REST endpoints with OpenAPI or Swagger.

  Suggested read for Java Developers: Swagger UI on MicroProfile OpenAPI

• Create a microservice A to consume some REST endpoints from the microservice B that you’ve created. You can start simple by consuming the GET operation from the microservice B.

• Externalize the configuration of your microservice A by allowing an environment variable to inform the URL of the microservice B.

  Suggested video: MicroProfile Config API in 5 minutes

• Stop microservice B and make microservice A fault tolerant with Fallback.

• Make microservice A take 1 minute to reply and make microservice B timeout within 10 seconds.

• Make microservice A responds randomly with a HTTP error, and makes microservice B retries the connection in case of an error. microservice A should always get a valid reply or a fallback at this point.

  Recommended read for Java developers: Quarkus and MicroProfile Fault Tolerance

• Implement a distributed tracing with Opentracing between microservices A and B. Tip: You will need to forward the HTTP headers from A to B.

  Suggested example project: https://github.com/rafabene/tracing-demo

• Implement Authentication in a REST endpoint of the microservice B and make microservice A propagate the credentials to microservice B. Use JWT - JSON Web Tokens.

  Suggested read to for Java developers: Build a REST API Using Java, MicroProfile, and JWT Authentication

Move to the cloud

• Package your microservices A and B in a container. Each one on one container. Publish them in a public container registry like Docker hub or Quay.io.

• Run your microservices A and B in a Kubernetes Cluster. For rapid and local startup you can use minikube. For on-premises production usage, you can rely on Oracle Linux Cloud Native Environment. If you want to try OLCNE locally, you can use this Vagrant file for it.

• Create a CI/CD Pipeline to take your source code to production. There are many solutions in the market. I’ve demoed Jenkins and Kubernetes in the video CI/CD Deployment pipeline using Jenkins on Kubernetes to deploy a Quarkus Cloud-native application

• Implement Kubernetes Liveness probe and Readiness probe. The Readiness probe should mark your application as “ready” only when microservice A can communicate with microservice A.

• Install a Service Mesh solution like Istio on your Kubernetes Cluster and perform some uses cases like the ones found in this Istio tutorial

  Suggested read to for Portguese readers: 10 Vídeos para aprender sobre desenvolvimento Cloud-Native

Next Steps

These are my recommendations to learn how to taker your CRUD application to a next level using different cloud native technologies. Of course, sky’s the limit as you can see at CNCF Cloud Native Interactive Landscape. There are other challenges that might appear and it will cause you to learn patterns like “EDA - Event-driven architecture”, CQRS, Sagas, Serverless, etc. But I don’t want to scare you. Like every pattern, you will only use any of them when you need it.

Furthermore, if you are a Java developer, please, subscribe to my youtube channel at https://youtube.com/rafabene. I’m starting a series of videos about the MicroProfile APIs. You can also help me by following me on Twitter (@rafabene), and you can also help other developers by sharing this content.

If you want to know more about a specific topic, just drop me a comment below.