Changing your architecture from a monolithic style to one encompassing microservices can have many benefits, but in a time when the tech community is still defining what microservices, serverless and even serverless microservices mean, understanding your options can get confusing.
To put it in the simplest of terms, the concept of microservices is primarily concerned with the way in which applications are written, while serverless is chiefly interested in the way in which computing services are consumed. Companies are now using a blend of these two concepts, known as serverless microservices, to rapidly develop or refactor applications.
To explore these somewhat abstract ideas, I thought it’d be helpful to think about something more concrete. Read on to see how microservices and serverless are just different aspects of transportation to help your application get where it needs to go.
Imagine your company wants to go to a team building activity that’s across town. The reasonable approach to getting there would be piling into a vehicle big enough for everyone going on the trip. Unfortunately, as your company grows increasing the size of this vehicle becomes more of a hassle. Do you buy a minivan or a school bus? What if you don’t plan properly and you’ve bought too much space, or too little? There are also challenges with scheduling and coordination. You need to take attendance and have an accurate projection of the number of people on the trip. You’re also stuck waiting for every single person in the group to be ready before you can make any progress. And should anyone need a potty break, the whole bus has to stop for them. It’s a strategy that starts out pretty simply, but gets complicated and inefficient as you grow.
Microservices is the radical notion that instead of packing everyone into the same vehicle, you find logical groups to break travelers into and put them into appropriately sized modes of transportation. Minivans, SUVs, Bird Scooters… your employees take whatever means of convenience makes sense for them. Not everyone needs to be on strictly the same schedule anymore. If your accounts receivable team wants to walk, they can. If a team grows, just get them a bigger car or split them into smaller teams and let them find their way. As chaotic as this sounds, it matches the way most of us get to work, so we have some reason to believe in its success. Growth is now represented by many small increases in complexity and cost, rather than the large chunks of the monolithic motorhome. Communicating between teams is more difficult, but manageable with a plan. Orchestrating the whole trip creates new complexities, but a dedicated resource with a certain skillset is able to handle it.
Serverless asks a different question. Who needs to own a car, anyway? Isn’t your problem really about moving people to different places? Sure, cars might help you do that, but do you really want to take care of putting gas in the tank, washing the windows, checking the oil, and parking? Serverless asks you to squint a little and ignore the passé notions of “cars” or “vehicles;” just tell us how many employees you have and where you’d like them to go: think of serverless as the Uber of cloud computing. Pay only when you need it for as much as you use it. If the trip is short enough, and you don’t need that many people moving together at the exact same time, just hit a button in an app and someone else will handle all of the details.
So clearly, you could use Serverless to drive your microservices where they need to go; depending on the work they do and the distance they travel, (or more likely, depending on the amount of computing power they need) and the time the task takes to execute. Computers have marched steadily from being room sized artisanal creations, to a commodity abstracted away from even geography. Serverless is the latest phase of evolution in that process.
An extension of microservices and serverless is serverless microservices. It’s an architecture pattern that many companies are using to rapidly develop or refactor applications. Conversations around microservices inevitably reach the point of talking about how small “micro” is. In the wild we’ve seen companies go “micro” by bundling the smallest amount of functions that make sense. If the smallest sensible bundle is a single function (or a handful), a serverless approach would have you let someone else wrap that function and scale as needed. The resulting application would then be a symphony of serverless services being orchestrated behind an API Gateway or some type of queue. In exchange for trusting them with this process, public cloud providers agree to bill you for only the milliseconds that these services are actively running. A few keystrokes or clicks on a console can replace entire procurement processes of old. Developers and businesses have yet another tool to leverage in their quest to create value.
If your organization or application could benefit from greater scalability, flexibility, or faster project development, utilizing microservices or serverless might be worth exploring. For an in-depth look at microservices, read our whitepaper “Microservices: Fast Path to Digital Modernization.”
About the Author
When not helping clients find their way to the Cloud, solution architect Jackson Stakeman can often be found drinking coffee or trying to raise a tiny human (preferably in that order).