Microservices — Please, Do

QArea's Founder, Maksim Garkavtsev, recently shared his perspective on the key factors of achieving business success with microservices software architecture on Forbes. For a business-centered perspective on microservices click here. For a deeper look at the architecture and how to work with microservices — keep reading!

Just in case the term is new to you and you happened to stumble upon this piece: microservices are a particular way of designing software applications as suites of independently deployable services.

This is a response to the numerous meandering articles, like this one, that have spread across the internet, generally claiming that microservices architecture sucks.

Building microservices is much more than just an annoying fashion trend in the world of software development. Yes, they already became a buzzing word on all technology-reviewing resources you can imagine, but its popularity explains itself: microservices get their job done spectacularly.

In 2016, Lightbend conducted a survey with over 3000 people from different industries (Technology, Financial Services, Online Services, Consulting, Telecom, Business Services) and professions (developers, architects, DevOps, CTOs, managers). Respondents answered the poll about reactive systems as a trend and optimal solution for business. The report claims the total of 83% believe that moving to microservices architecture or “going reactive” is undeniably gaining momentum and spreading into businesses globally. The major 43% of those respondents claim they have already adopted the approach, while 40% stated microservices development to be “totally important, something we needed yesterday”.

Let’s figure out the key misconceptions that provoke much confusion and are capable of misleading people on the way to a crucial choice of the optimal software development model.

Misconception #1 Microservices implementation is too hard

Lazy programmers claim that microservices architecture is too complex and takes too much time to develop. It also requires deep knowledge and years of extensive programming expertise. Technically, this is true. However, we can say exactly the same thing about everything. Playing chess requires expertise, so as does building the house, so does building monoliths.

If you are motivated enough to make a high-quality product — microservices architecture will bring the expected order in the whole system management. It’s worth spending the time and resources to make that happen. Along with automated testing and deployment — this architecture will unveil even more benefits in the form of easier management and smarter prioritization. Moving to microservices allows several developers to work with the code simultaneously without interfering each others’ processes.

“You need a big team of programmers, and one DevOps to manage a monolith. You need a couple of programmers, and a big team of DevOps to manage microservices. Yes, numerous sections that build up the software — need to be constantly maintained. Still, for our projects we did not see options that are better than microservices. Monolith is not scalable, it requires lots of time to add new features or just simply fix a small bug that was missed during automated testing. There’s one undeniable benefit of microservices that beats all advantages of monoliths: faster time-to-market”

— Andrey Osipenko, Project Manager at QArea

Misconception #2 Moving to microservices can create a mess

Every code can be messed up. Everything depends on the people who write it. Programmers, who are diligent and motivated enough to create a flawless machine will manage to make it real. Putting all the blame on microservices architecture won’t make your monolith better (if this is what you opt for). Be true to yourself and measure your capabilities. Learn how to get started with microservices. If you are simply not ready to put big efforts, money, and time into software development — it’s a sign of a much bigger problem than architecture.

“The key to clean and consistent code lies in equal decentralization, which is the main principle of microservices. Since every separate service is responsible for one bunch of operations, it’s much easier to make changes in the code and not to be afraid to deploy them. Also, for each service you can use different tools, which increases their performance. For example, some services can be kept in SQL database, while the others better be stored in NoSQL database. Microservices provide more freedom and possibilities than monoliths. It’s a fact you just can not argue.”

— Vyacheslav Pinchuk, Golang Developer at QArea

Misconception #3 Microservices architecture is too hard to manage

Continuously deployed systems have far more potential from the point of business growth. It’s a fact. Monoliths can be good as a starting point for startups. But full-edge, complex software, with rich functionality, and millions of active users demand a flawless system. Monoliths just can’t handle the pressure and usually tend to suddenly drop from unexpected load swings.

Microservices architecture officially appeared as the term in 2005, and for many years of existence it evolved, introducing numerous tools for execution. Each service can be written using different technologies, because microservices are flexible. Monoliths simply can’t provide you with such freedom of choice. Kubernetes, Swarm, Finagle, Dropwizard, Spring Boot, Netflix Eureka, Ribbon, Hystrix, Nameko, Mesos, Marathon, DC/OS, Docker, Heroku, and even more tools/platforms/frameworks are at your hand to create a powerful software that beats any perfect monolith in terms of scalability.

Management of microservices architecture demands the team of highly-professional developers. It’s true. Still, monolith architecture also can’t be maintained by Juniors. If your DevOps believes microservices are “mission impossible”, you are probably going to stay within monolith architecture for years. Or you can hire a new DevOps professional. Experts, who have at least two-year background of consistent microservices management — will never be afraid of challenges again. The smartest way to manage microservices to avoid overloads, is to equally spread responsibilities between the teams/developers. Every experienced DevOps engineer tackles it just fine.

Misconception #4 Microservices are slower than monoliths

Let’s be objective here: each architecture can be slow. Everything depends on the code quality. Microservices take a bit of time to process integrations between the services. Monoliths, on the other hand, are time-consuming in terms of deployment, they are hard to scale, and usually are messed up after.

Microservices architecture is autonomous, hence less prone to system failures unlike monoliths. In case of trouble during deployment — decentralized systems are much easier and quicker to fix. So the question we need to ask ourselves is: Do you want your software to perform great, without sudden failures but take more effort to maintain, OR you want your software to be easily-manageable but without guaranteed resistance? The choice is yours.

Netflix, Amazon, Twitter, SoundCloud, Uber and other lesser known companies like Segment — created a cargo cult that now simply can’t be denied. Admit it: this type of architecture could not be adopted by so many companies who successfully run their businesses without a reason. Also, the “success stories” usually showcase drastic revenue changes exactly after switching from the monolith to the microservices.

The good, the bad, and the ugly of microservices architecture

Now, let’s sum up the above. Microservices can be different. They can turn out the best solution for your business or create a total mess, if you put small efforts. We believe there are three sides of microservices, and here they are.

The ugly

Microservices architecture is hard to manage in terms of security. Due to its decentralization, it’s difficult to come up with one solution that protects all independent components, and more importantly, API calls, without feeble spots. Every problem has a solution though. Netflix has a very good article on famous DDoS attacks on microservices.

The bad

Okay, let’s all agree that microservices architecture takes more time and resources to be developed to correspond to the high-quality coding standards. Distributed Services as an alternative to microservices and monoliths can become a good option if you’re too afraid of drastic changes but still want to move to a decentralized architecture.

The good

The goal of every contemporary business is to improve time-to-market delivery. Microservices architecture is revolutionary. It eliminates organizational friction, providing engineers with desired independence and autonomy to unceasingly improve, iterate, and deploy. The complexity of microservices is exactly what makes this architecture type so full of benefits: it’s resilient, elastic, agile, composable, message-driven, responsive, reusable, and bla bla bla. All cons can’t compare with so many pros microservices development is capable of bringing into your business. If you have a dozen of highly-proficient DevOps — microservices will bless you with continuous high concurrency and stable performance.

We foresee how the tons of arguments pour in the comments still claiming microservices architecture is lame. Feel free to discuss, object, and support the article. It won’t change the fact that thousands of companies all over the world choose this solution for a variety of businesses.

By the way, our team of developers knows everything about microservices, and builds high-quality desktop, web, and mobile applications for over 18 years now. Contact us if you want to create a super-powerful software.

The article was originally published on QArea blog.