Micro services that makes great deliveries — The Survival Guide
One of my challenges, working as a developer for ClubPetro Fidelidade was to transform the company big monolith into few, independent micro services. The first thing that I thought was:
“That is just a hype that hipster tech guys are creating to , make software. Monolith or whatever is that we have, is fine !”
— Naive Pedro Vallese from the past. (I was wrong)
This text is to show what I’ve learned from these past few months studying hardly on the subject. What you should do, what were my mistakes so you don’t make them, cloud architecture, good methodologies, and many other stuff so you can finally build micro-services that delivers value
This text is divided in some steps so that you can easily go through some unnecessary subject that does not concern your case and go to what matters most for you. The subjects are
1 — Why Micro Services and why not.
2— Main concepts to master Micros Services.
3 — Cloud Tech
I’ll be referencing all the texts and books that helped me create this one, so, if you’re really interested into building Micro Services, I recommend that you take a look in the texts referenced. So, let’s begin!
- Why micro services and why not.
The most important thing and first thing to know about micro services is that it’s concept is not about the functionality of your software, it’s all about the architecture of it. You can build a monolith that does the same thing as a decentralized software but it will be big and hard to scale. Maybe, your product/project does not really need a micro services architecture, and that’s okay, you are not a worse programmer because you don’t work with micro services, but you should know when it’s right to build a micro service or when to build a monolith.
Why
Adam Berthan in his text, explains in a very eloquent form of why you should go for micro services, the four main things to have in mind is:
- Resilience
A single software that have many features and clients may become unreliable. A bad set of codes for a new feature may corrupt all other software that was built, maybe the constant access and lack of hardware may deliver bad experience for not only the ones using a high demanded functionality, everyone will have a bad experience, with micro services when you insert unreliable software, it’ll only affect itself, all other services will be the same as they were before, the maintenance will be easier to find and to deliver since you know what service is buggy because of independence of your services.
- Scalability
Using the case used as an example before, when you have a service that have high demand of requisitions and processing power you can scale only it, this process will be easier and cheaper, it’s easier to do it if you use services on the cloud and kurbenetes (it will be discussed on the cloud tech section).
- Right Tool For the Job
With micro services you don’t need to always need a team that programs in a specific language, or a huge computer that takes care of your whole program, you become much more flexible with micro services. Take node js technology for example, it is great to take care of huge numbers of API requisitions, but it can’t handle mathematical process as well as other languages, in this case you can build a Python micro service which is a technology that is good with numbers and can even do some machine learning process with data. With micro services, you can easily adapt the technology to your problem and not the other way around.
- Teams
With micro services you can divide your teams in smaller groups that have simpler tasks, being much more agile that it was before. If the demand is bigger than your staff, you can easily hire freelancer to get the job done remotely, they will not need to have access to your code that may contain sensible information. The only thing you need to do when working with remote teams, is leave the business rules well documented, and let them build the code, since it’s a micro service the job will take a month or two, once they’re done, give the code to your DevOps guy and done! The task is all sey, your freelancers might not even know what the code was for, but they followed your documentation and delivered what you asked.
If you have large set of products in your company, want to respond fast to your customers desire and want to deliver quality in your user’s experience. You should go to micro service. A Brazilian Fintech called NuBank had this desire and from its stretch built a micro service that delivered an excellence in availability and experience. (You can read some of it here).
Why not
Micro services, although is the next cool thing for the hipster dev kid, it is not for everyone. It’s always important to remember one simple thing from the agile manifest:
7: Working software is the primary measure of progress. … Goals of agility are to go deliver software
If you have a monolith, and this software delivers what is supposed to, you have to be very wise to change to a micro service architecture. Micro service is next-level developing, many developers don’t have the culture and the cost of operation may not be worth your while. Even if you are not happy of your software, you can deliver something like this:
Micro services have complex design and architecture, the dream to turn your code structure into simpler and independent processes can be turned into a living hell. I highly suggest, after reading this arcticle, taking a look at the Building Microservices from Sam Newman. It’s highly important to understand all the challenges and technologies to build an actually better architecture, otherwise a bad code will just be turned into smaller, independent bad code.
Main concepts to master micro services
DevOps & QA Culture
Continuous development and continuous operation. That is the main core of the DevOps concept. You will need to automatize the deployment of your apps with very consistent pipelines of deployment and integration (know as CI/CD pipelines), the process to build manually will just be too costly, imagine, dragging your files to your server domain, compile it, run it, check if it is fine, all this process for each microservice.
You’ll need also to monitor your API traffic and response to check if your server is running smooth, this process is already complex with monoliths, with microservices it just gets worse. DevOps culture is essential for building a microservices' architecture. Also important, the operational cost to maintain a server and not go to cloud computing is much higher, this makes much cheaper and easier to deploy it all on a cloud service system such as: Azure, Aws or Google Cloud.
Also, building code with quality is essential, you’ll need to have very strict pattern of quality. It’s important to have automated tests to check if your code does what your business rules said it should do. Documentation and good practices of code are also key so microservices can communicate with each other smoothly.
Domain Driven Design
The most important thing to consider when going to microservice is getting to know how to design your system. The big ball of mud, is the concept of a monolithic architecture that have too many business rules and functionalities that makes the system too confusing, leading to heavy and buggy software.
To help you divide and conquer your complex system there’s the domain driven development methodology. With it you’ll be able to figure out how micro should be your micro services and how to architecture them. DDD is a very dense concept and more intangible than software itself, so be ready for some heavy reading. Luckily there is the book Domain-Driven Design Distilled by Vaughn Vernon is a book that delivers its concept in a small and “distilled” way, but consider taking a look on the original book by Eric Evans: Domain Driven Design.
Cloud Tech
The goal in this chapter is to explain a few technologies that will help in building your decentralized software. Imagine that you build some servers in node, and then you have dockerized it, how will they communicate in a synchronized way? How to keep it safe from other attacks? There are just so many problems involved with working with multiple dockers that will turn your microservice dream into a software hell. But, wait we have solutions! There are docker and virtual images orchestrators such as Docker Swarm and Kubernetes. In this post I’ll be covering about Kubernetes, but feel free to search about other softwares that may fit your needs better.
Kubernetes
Kubernetes is a technology developed by google that works great for services communication. All of its functionalities and concept need another post just to get started. Here are some main reason that makes Kubernetes so great:
- Load Balacing and Replicas: With Kubernetes you can deploy a service and create replicas of it that communicate with a Load Balancer service that redirects the traffic to the replicas the way you want. This helps a lot with availability of your software and chaotic situations such as server failing.
- Infrastructure as a code: With just a few scripts, you can create services that talk with each other and easily set up a microservice system.
These are some Kubernetes features, you can dig deeper into it with the book Cloud Native DevOps With Kubernetes, by John Arundel. In this book he explains how to work with Kubernetes in the cloud in a very enloquent form. The most important subject that he presents is…
Kubernetes is hard
Although it keeps things easier, kubernetes is a tool that is easy to get started but hard to master it. I have stumbled upon very hard challenges that took me a week or two to handle it. If your team dosen’t have the time and will to master Kubernetes it is alright, there are other ways.
One way to go is going serverless. If you don’t have a good DevOps culture, handling servers and building pipelines is a pain for your team, serverless architecture contemplates all the microservices concepts and may be a way for your team to thrive. This way, your team will only care about the code. There are its pros and cons though, I suggest taking a look at this article also by hackernoon.
Pricing
There are a lot of cloud tech out there, getting the best service with the lowest price I believe is a dream for any buisness. To choose what cloud service to use I searched the web by its price until I found this arcticle. Google Cloud Kubernetes have a cheaper service and with great support. In a few weeks using their platform some Google Engineers contacted me and helped me out with my struggles using Kubernetes.
Streaming data
Last but not least, one main technology that a developer’s gotta know while working with microservices is the famous streaming data tools such as Kafka and Google’s Pub/Sub. Those services give the architecture to deliver data to different systems. It works like this picture: Imagine that all your data is in your data streaming lake, and all of your services are your flamingos fetching the data that is avaliable and handling with it in it’s own way.
A Streaming Data Service keeps incoming data avaliable and consistent for other services to handle in it’s own way.
What are your thoughts?
That’s all that I can share about working with microservices, if you have any questions in your daily strugles as a developer, comment bellow. I hope you guys enjoyed the text, it took me a while to write.
Keep on Hacking.
