New technology is great. It's very important to open space for new ideas, better solutions, cheaper, faster and exciting new things. However, even with technology, there are principles and lessons learned with previous technologies we need to carry on otherwise we will keep making the same mistakes and we might not take full advantage of new tech. Why? Because often new tech requires a new way of things and often times also require to keep some things from the previous movements. Companies want to do Serverless now a day, often because cloud vendors are pushing that hard and because of the short term cost benefit. However, in the long run, Serverless solutions might be way more expensive than in-house solutions using OSS. There is no silver bullet, you need to understand what you are doing in order to take full benefit from new approaches, techs, and ideas rather than just moving everything from on-trend to another. I want to share some thoughts from several architecture models and principles that was evolving from SOA to Apis to Microservices to Cloud-Native Microservices to Serverless. For instance, Serverless is going forward following some SOA Principles, did you know? For this blog post, I will provide a set of explanations on my view of the architecture evolution and at the end of the post you will have access to a 40min video, explaining some ideas on the post but with a video.
From SOA to ServerlessSOA is not about technology(SOA is not about ESB), SOA is about principles, these principles are alive nowadays more than you can imagine.
SOA was the foundations of everything. SOA is about abstractions(contract) and the big picture(Service Orientation - SO), seeing the whole system spectrum and it should not be used or a simple Service alone or single project alone. One of the main benefits of SOA is the
Backward compatibility(BC) approach. Soa is not a specific technology neither just an ESB.
Microservices are a kind of SOA with 2 different aspects. First of all the granularity which is smaller than SOA, SOA never gave a prescription on who granular a service might be but in my experience often was quite big. Seconds Microservices are about
isolation. In other words, having they dedicated OS, Servers, Git repository, Build the pipeline, and so on and on. Microservices requires lots of DevOps work. Microservices are not the silver bullet there are problem domains where it does not make sense to have small granularity and therefore this could lead to bad design and coupling. It's very important to talk about SOA in Microservices and Serverless context because these architecture models evolve from one to another and if you just see Serverless as a self-contained thing (meaning: not learning from SOA and Microservices) you most likely will be doing it wrong.
Microservices required DevOps Engineering. When we are doing microservices on the cloud, we can use most of the benefits from the cloud by doing cloud-native microservices which you can be done by using NetflixOSS / Spring Boot Stacks or nowadays you can use Kubernetes with
Istio.
What is Serverless?FaaS and Serverless are different things. Often people think Serverless is about FaaS only. Often Serverless is related to FaaS. However you most likely to have Serverless when you are doing FaaS but you might be doing Serverless and have no FaaS. Because Serverless is a cloud model, where often the cloud provider takes care of the operation for you. This is the case for Managed Services for Databases like Aurora but also for other engines like
Kafka, MongoDB and much more. FaaS(which was called microservices for a brief moment - for some people) is the evolution of microservices, however, FaaS is Event driven and microservices can be Event driven but also can be RPC.
Serverless and KubernetesKubenetes is the cloud multi-cloud / poly-cloud way to go. Ks is the open source / open standard cloud spec, which means, you can use cloud without getting locked-in by a cloud vendor. Kubernetes allow you to run all kinds o workloads from RPC, Analytics / Batch / Streaming, Machine Learning Training and also Serverless. The cool thing about running Serverless in kubernetes is the fact that is all portable, not only the code running in Serverless but also the whole infrastructure which is great. Somewhere in the future cloud should be about COST them being able to move things around is better not only for better usage of cloud reservation but also for strategic negotiations.
Serverless Require less DevOps work, it does not mean you can do NoOPS. It means you have less DevOps / Ops work. You still need to automate the deploy of your functions(in case you are doing Serverless with Faas), if you think about CloudSQL or RDS you will have more things to automate. Serverless end up has less moving pieces from you and more pieces for the cloud provider whoever is providing the Service.
There is an open spec for Serverless called *
Cloud Events*. Cloud events describe the events(inputs, outputs) in a standard way. Does this sound like an SOA Contract? Yes. We also see the same willing to have portability like we saw in SOA Manifesto. IF you don't think this is the future you don't need to take my word from granting take
Kelseys. VideoNext, you will see a brief story about the evolution of Service architectures, starting from SOA and getting into Serverless on Kuberntes. You also will see some benefits and trade-offs of each wave of technology evolution.
Reflections on Serverless from
Diego Pacheco on
Vimeo.
Slides Doing Serverless without Kubernetes is a recipe for Lock In. Serverless need to embrace SOA values like Open Standards, Contracts(Cloud Events) and API Versioning / Backward Compatibility features otherwise your system will continue to break and you might take full advantage of Serverless.
Cheers,
Diego Pacheco
