People enter into technology thinking they can pursue an idea that will make them a lot of money. If you read startup stories you will find that most start with an idea, evolve into a business, become broke, rebound and make millions…. or end up being broke and learning a lot.
I’ve read these stories but I am not a risk taker. Maybe I just don’t believe in my ideas as much as others or lack the confidence to pursue them.
Functions as a service (FaaS) have really become a staple in most development circles. They provide little infrastructure overhead in the development of microservices and are often very lightweight. Yet FaaS face their own sets of challenges when it comes to costs, response times, and observability.
I believe that architectures will evolve over time. In some cases you may never want to change your FaaS but there may be cases that you’ll want to move it to it’s own application.
To be honest, I’ve had a rough time understanding how FaaS fit into my vision of a microservice architecture. It made sense that they were microservices themselves, especially when they are event driven: put something in a bucket, then do something, maybe do something else and so on. But what I didn’t understand was why build a serverless function if you could build an API.
In the end I realize that it was how I had learned to develop microservices that was the crux of my issue.
My last couple posts have been about developing and designing cloud based applications. In the What Are Microservices blog post I wrote about the importance of having small shippable applications that can easily scale depending on demand and are decoupled from other services to allow for faster development and independent deployments. In A Tangled Mess we explored how to decouple the systems even more by publishing events as they occur and having other systems react in appropriate ways.
The goal of microservices is to produce independent systems that have loose coupling. This allows for the ability to manage and release upgrades without impacting other applications. However, many first implementations of microservices make the developers believe that the only way to communicate with another API is through a client. Thinking that obviously this is part of the whole process, they design many APIs that rely on other APIs and the chain goes on and on, and in some cases back to the original API for more data.
At the beginning we all start building an application. Then some part of it takes off and before you know it you are throwing new pieces on the original application until it becomes unweildy. Thus is born the Monolith. In time your system gets large, cumbersome, and hard to maintain. Then you hear about microservices (or maybe you started that way because it was in fashion when you started development) and start building them.