After I have been reading a few books and see, there are lots companies now day are still running their application in monolith architecture or maybe war file. I thought , I should share my experiences and opinions in to this blogpost. I do hope that, this could be bring some more information to you to getting start with their journey about microservices, containers and scalable software.
Here are some steps I worked it out, please don’t get me wrong:
- Identity and implement the new functions of business around microservices concept
When you would like to scale your system, you might need to to break down your service to be small piece and scale independent and reasonable.
Learn how to group the services. Do you need group them by domain, team or bound-context?
So by stop adding the heavy jobs to the existing application, we need to identify and implement them with new domain and small service. Why?
A small service, will bring the team easy like
- Easy to test,
- Easy to deploy and independently
- Easy to maintain, one team could work 1,2 services based on organisation structure
- Easy to scale based on functions we required and independently.
- Easy to change and adopt agile
Now you are continue to create the new service in microservices design. Your services will be grown rapidly.
So right now you had a big monolith application running the same time with lots small microservices. One day your monolith will be gone or less enough to be kill.
2. Understand the complexities of microservices
When you have a lot of services running as distribute system and they are communicating each other through REST API, messaging, gRPC so on. Your complexity will be increasing.
Example: If your exiting application or your new service external-gateway connecting to other service like fraud-service, if something has been responded failed like timeout, exception thrown, more than that. How can you make sure which one is the failed and why/what? How do you prevent the entire services down? If fraud-service down, other services are going to down too? Are they still continue to running without making the customers are unhappy a whole functions? Yeah customers should be able to getting the report, because fraud-service is down. Shouldn’t be impact the report-service? isn’t right?
- How you manage all the configurations for those services
- if you would like to scale service two or more instance how you provide the client load balance to these services.
- If my external-gateway call to external system partner failed, do I need to call it until my consumer who consume my external-gateway to be fail too?
- Security is the most concerns and should be on the top of mindset. How can we control the security around those services?
- Logs are became more places to check? Do you need to go to each container, vm to check the logs?
- Now you had a lot of services, how you monitor it? Jump in and check one by one? No! No! We can not have hundreds screens to monitor hundreds services.
If you are interested on microservices trade-offs, this one for you.
3. Pickup the frameworks and tools
Pick up the tools is the most important decision. Since there could be impact the whole developers team, QA, architecture and even organization.
If your company is using Java framework, then these are the frameworks you might need to consider. I’m mostly working on java stacks, so I can list down here. If you are using other programming language, yeah sure you can just google like {Your primary programming} microservices framework.
- Spring Boot and Spring Cloud
- MicroProfile
- Vertx (if you prefer reactive style)
- Quarkus (if you would like serverless style)
- Micronaut (if you would like serverless style and your developers had experiences with Spring)
DevOps tools:
- Jenkins
- Docker,
- Kubernetes
- OpenShift
- Ansible
- Tekton
Logging, Tracing, Monitoring and Metrics
- Prometheus
- Grafana
- ELK or ELG
- Zipkin
Testing frameworks and tools:
- JUnit
- Robot
- Mountebank
- Testcontainers
4. Are you prefer to run your microservices with war?
If your software is running in VM or war file and you are new with containers , swarm, kubernetes, container platform and not confident it at started. I would recommend Spring Boot and Spring Cloud.
Spring Boot and Spring Cloud has bunch of solution to solve your problems and complexities with microservices architecture.
- Spring Cloud Gateway: APIGateway and Routing
- Spring Cloud Config: Centralised Configuration
- Spring Cloud Circuit Breaker: Rate Limit, circuit breaker pattern, timeout,etc.
- Spring Cloud Sleuth: Tracing
- Spring Cloud Stream: Even-driven framework based on Enterprise Integration Pattern
- Spring Cloud Vault: Integrate with Vault secrete management and adding to application property source.
- Spring Cloud OpenFeign: Client load balancing
- Spring Cloud Contract: Consumer driven contracts
However you still can use of these in container. No worries on this. You also can use Spring Cloud Kubernetes if you are going to containerised your apps or using k8s.
5. Automate everything AS MUCH AS YOU CAN
Whatever your software is running on VM, Container, k8s or OCP. We have to automate everything as much as we can.
Automate will improve the speed, security, software quality and reduce the toil. Learn how to eliminate toil .
When the developer pushing the codes to git repository and merge with the master branch, our automation tool — maybe (jenkins) is going to build, running the test, reporting the test, vulnerability scanning, and deployed it to dev environment, etc.
Make sure it provides the fast feedback to developers and they felt confident on it. Trust is a motivation who making them happy!
6. Are you new with container
- Getting start with Docker
- Package your war file or jar file to container image
- Running these in your non-production environment and play-around with it
- When you are more familiar with Docker, You can running application docker swarm even in production.
- When your application need to have more workload, handle failure case, using effectively resources. You should probably check container orchestration like kubernetes,OpenShift. If you are using cloud, almost of them already provided kubernetes platform build on top of that already. Example: Google Cloud (GKE), AWS(EKS),etc.
- Then you can start with kubernetes by understanding the concepts of: Pods, Deployment, Replicas, Service,ConfigMap, Secrete, and Ingress. Using tool like minikube, kind , minishift, to practice it until you realised , it’s outcome works for you.
- Installing the docker, swarm, kubernetes or OpenShift will making your TechOps team more sleepless. They are working around of cluster. So there are a lot of machines have to be installing and working. So by automate this job then you should go forward and getting start to use the tools like ansible, terraform, etc. Now you are getting comfortable. Aren’t you?
- Yeah if you are ok above steps, you now should be able to start with containers and cloud-native application.
7. Now your software should be scaleable
Now you might have the microservices architecture running and maybe your application running as container. So now you can scale and speed up your software released to production faster with automation tools and container workload/orchestration to make zero deployment downtime.
8. Don’t forget to keep you update
Yeah looking the news of techs like podcast , following community might help to keep us in a place which can watch how are the technologies going on. What are they? Can we benefit from them? Will they make our developers life easy? Deploy faster? Automate faster?
