Darren Bathgate is a technical architect at Kenzan, a software engineering and professional services company in Pawtucket. With a master’s degree in information technology from the New England Institute of Technology, when not designing data models, he speaks to local tech groups about microservices.
PBN: First, can you provide the less tech-savvy among us with a basic explanation of microservices?
BATHGATE: In order to understand what microservices are, we have to start with the basic layout or architecture of web applications and what a “service” is. Sites like PBN.com have a graphical user interface. This is also referred to as the “front-end” and is what users see in a web browser. It is how the website looks and feels; it’s the forms, buttons, tables of data, etc.
The front-end interacts – typically over the internet – with the back-end of the web application, which runs in a data center. The back-end tends to be larger and is responsible for supporting the front-end. Think of the front-end as the tip of the iceberg that you can visibly see, and the back-end as the enormous part of the iceberg you can’t see. The back-end does the heavy lifting for the web application and would be responsible for things like processing an order from someone’s shopping cart and returning order confirmation information to the customer.
This back-end application fulfilling those user requests is what we call a service. Before the adoption of microservice architectures, all this back-end service functionality was typically deployed in one large implementation. We call this a monolith. Monolithic services are a single application that is responsible for serving requests for the entire site or product.
Monoliths grow in size as they gain more responsibilities, or more functionality. We begin to encounter scaling issues when monoliths become too large. Microservices are when we decompose parts of the back-end into smaller components to support the front-end. This decomposition creates multiple services, called microservices, that are now smaller, and scale becomes easier to manage.
PBN: I’ve read that microservices can help companies “evolve a technology stack [combination of programming languages, tools and frameworks].” What does that mean?
BATHGATE: Microservices … are often considered the evolution from the old way of doing things. But there are pros and cons to both ways. Transitioning to microservices can mean a fresh start. An opportunity to do things in a different, more modern way. Think of it like getting a new car because the old one is underperforming. You wouldn’t go out and get the same year that you had before. You would instead get a newer car with the features that supersede your old car.
For the majority of companies making the switch to microservices, they will also get to upgrade their technology stack to the latest and greatest. The technology stack is in a constant state of change, and companies need the ability to evolve. Microservices are agile; their small size enables change to occur more frequently without large impacts. This constant change comes at a cost of continuous learning and cultural adoption.
PBN: Can microservices help minimize damage in terms of, say, a cybersecurity breach?
BATHGATE: Choosing new technologies for the microservice stack may improve the security of the previous generation monolith if it was running on outdated and insecure software, as long as they are built with security best practices.
Securing microservices is, however, a much larger chore. Consider a monolith as being a house with one door. That door has a specific lock. Now consider microservices as a house with multiple doors, each one with a slightly different lock. Securing that one lock for the monolith is easy, but trying to do it for every microservice is hard. Microservices require strict governance to make sure everyone in the company is using the same secure lock.
We can also design solutions to reduce the impact if one microservice was comprised, essentially adding multiple layers of doors. Microservices enable patterns like isolation to create barriers from one service to another. Isolation prevents a malicious user from traversing from one compromised microservice to a potentially more sensitive area on the network.
PBN: Are there any kinds of companies where microservices would not be a good fit, and why?
BATHGATE: Microservices can have many benefits for businesses. … It’s easier to maintain applications, bugs are found and fixed quicker, development teams work faster and are more efficient. However, the implications of introducing any new technology … reaches more than just the IT department.
Any business that is undertaking the adoption of new technologies also has to consider the impact it will have on [its] teams and the processes in which they work. If a company isn’t ready to invest in those areas as well, with things like continuous education for employees and organizational changes, [it] might not be ready for microservices.
PBN: Is a large part of your role education, explaining microservices and how they work, for example, to clients?
BATHGATE: Most of the companies that we work with are already at some point on a digital journey, so microservices aren’t typically a foreign concept, but knowledge varies. Education, however, is a big part of what Kenzan does. A lot of software-development companies go into a client, build a platform or application and then leave.
We believe that in order to get real value out of technologies like microservices, you have to do more than just build the next-generation product. The nature of the tech landscape is that it evolves quickly. … I provide the critical knowledge, skills and tools that enable development teams to continue to grow and learn, which is really the key to sustaining success.
Susan Shalhoub is a PBN contributing writer.