This post is the first in a multipart series exploring the basics of microservices. Check back each Monday for additional installments.
Microservices have got the tech world, and especially DevOps circles, buzzing. And no wonder, since this is the perfect technology for taking advantage of the cloud computing delivery model. As with any rapidly trending Next Great Thing, however, it can be tough to sort through all the hype vs. how microservices actually apply to every day, rubber-meets-the-road project work.
For those ready to learn the practical basics and application of microservices, The New Stack gets the low-down from some of this emerging sector’s thought leaders.
What are Microservices, Anyway?
Microservices are an architectural approach to software development based on building an application as a collection of small services. Each service has its own unique and well-defined role, runs in its own process, and communicates via HTTP APIs or messaging. Each microservice can be deployed, upgraded, scaled, and restarted independently of all the sibling services in the application. They are typically orchestrated by an automated system, making it possible to have frequent updates of live applications without affecting the end users.
As a natural approach to optimizing work, we are already comfortable with the concept. Think about it: These days, your average cloud consumer — including adamantly non-technical people — easily and naturally uses multiple cloud products that are, essentially, micro-products and micro-apps. (They don’t call it “The App Store” for nothing). While an average enterprise organization uses, at minimum, a dozen different software products and integrations: one tool for logging business expenses, another for schedule tracking, another for payroll management. You get the idea.
It just makes sense to embrace compact and specialized tools that get each job done properly. Microservices are exactly that, scaled to enterprise level.
Think of microservices as Lego blocks snapping together to build a unified model. First, developers identify the separate service “pieces” necessary to build their project, such as search, authentication, messaging, sales processing, etc. Then they choose from the smorgasbord of options available, from open source to turn-key enterprise solutions, and knit everything together into a functional application.
A Word About Containers
The terms “microservices” and “containers” are often used together. However, containers and microservices are not the same thing. A microservice may run inside a container, but it could also run as a fully provisioned virtual machine. That said, container-based — and open source — systems like Docker and Kubernetes are a very effective way to develop, deploy and manage microservices. Many mature and robust tools, platforms and other services already exist in the container space, rendering containerization a natural fit for microservice-based applications.
Benefits of Microservices
“It’s very simple: microservices save developers from having to waste time reinventing already solved technical problems,” said Jamie Dobson, co-founder and CEO of Container Solutions. By enabling small autonomous teams to develop, deploy and scale their respective services independently, Dobson continued, microservices essentially “parallelize development” — thereby speeding up the production cycle exponentially.
Additionally, Dobson noted, continuous integration and development are basically built into microservices architecture. “Microservices take a lot of infrastructure risk out of the project straight away. With the infrastructure made almost invisible, microservice teams can iterate quickly, often in hourly cycles, so that value is increased while ‘wrong feature’ risk is decreased in a continuous fashion,” he said.
In other words, in microservices, each developer on a team gets to forget about underlying infrastructure and focus on their piece of the project. Then, in production, if individual project modules don’t work exactly right together, it’s easy enough to isolate, disassemble and reconfigure them until they do. Again, kind of like Legos.
Are There any Potential Drawbacks?
Microservices are the antithesis of the classic monolithic app, with obvious benefits. However, as with any developing technology, the early adoption curve can be steep. Currently, the approach is most effectively embraceable by super-sized companies like Netflix and PayPal, who have been able to shift to microservice architecture thanks to robust in-house resources and engineering teams.
“It’s great when you are a very large, resource-rich enterprise, with individual teams able to manage each service and ensure reusability and discoverability,” said Matt Biilmann. Biilmann is CEO and co-founder of Netlify, whose all-in-one platform for developing and automating web projects recently added a microservices gateway. He added that Netlify has noticed increasing traction as well with individual developers “playing with microservices for small projects — mostly because they’re pretty fun!”
However, Biilmann continued, the pain is real for everyone else in between. Moving away from a monolithic app architecture means the loss of an opinionated workflow that glued all the pieces together.
“As we split up monoliths into microservices, we risk getting a very fragmented system where developers need to spend a lot of time and effort on gluing together services and tools, and where there’s a lack of common patterns and platforms that makes working across projects viable,” he said. “The possibilities are awe-inspiring, but in order to truly take advantage of them, we need vendors to emerge that can build the glue that enables a one-click setup.”
As an illustration, Biilmann pointed to the emergence of the LAMP stack. Freely available tools like Linux, the Apache web server, MySQL and PHP opened up new possibilities for web development — but the architecture truly took off when companies built integrated tooling around projects like WordPress, Drupal, and Joomla. “You don’t start up WordPress by setting up Apache and setting up a MySQL database and configuring them to talk to each other. You expect to go to a panel and click a button that says ‘start a new WP project.’ And you can do this because at a certain point there was enough momentum for the industry to build out the stack that could make it a one-click setup. This is essential for widespread adoption of any technology.”
Fortunately, the same market leap forward is now happening with microservices. There is a virtual tech sector land rush on, with companies feverishly producing not just microservices themselves, but platforms, tools and frameworks necessary for joining them seamlessly together.
Ask Your Doctor if Microservices Are Right for You
At this early stage, however, it can be difficult to gauge both best fit and ultimate longevity for these emerging resources. Not to mention that microservices can also require increased testing complexity and possibly increased memory/computing resources. Thus, despite the abundant potential benefits, those knowledgeable in the field caution that microservices are not automatically the right solution for every project.
One veteran consultant, who specializes in transforming legacy enterprise applications and asked not to be named, said that he remains a fan of monolithic architecture for certain scenarios. “When you are running multiple instances of the same service or worker, you don’t necessarily need microservices. A well-built monolithic system can scale just as well for some classes of problems.”
Furthermore, he said, it is entirely possible to create unscalable microservices. “It all comes down to how well you apply the fundamental principles. It’s all too easy to jump into shopping for all the microservices you want to apply without first truly considering the problem set you’re applying them to.”
The Next Frontier
In a true microservices approach, you are running only the exact small services you need — and nothing else. It’s a sleek setup, but these services are not aware of each other until you also step in to orchestrate them. Until recently, this implementation and orchestration piece have been beyond the engineering reach of many smaller to mid-size organizations.
However, we are now approaching critical mass in terms of infrastructure and support around the technology.
“Microservice architecture is faster, safer, cheaper — much of the time, it’s the better way,” said Chris Bach, Netlify’s other co-founder. “The next step was accessibility — viable workflows. Now we are seeing the ends meet, front and back, and when that happens, you know that momentum has been achieved.”
Meaning that microservices can now become just another tool in the developer’s toolkit.
Next up: How to approach evaluating microservices as the right architecture for an application, and whether your organization is equipped to build applications this way — both technologically and culturally… And what you need to know to prepare for the transition.
Feature image via Pixabay.