In the last few years, there is no doubt that cloud computing has become one of the main pillars in the software market. Public Cloud providers like AWS or Google Cloud went way further than just providing servers in the cloud, they created a tone of services abstracting a lot of the infrastructure allowing faster development. In fact, they created such an ecosystem that combining those services has become the real power of public clouds.

‍

‍You can mix AWS API Gateway, AWS S3, and AWS Lambda to build your own file storage application

‍

This is awesome, as it simplifies the number of decisions you need to make to choose the right technology, join them together, provision APIs, etc. But still, there’s something that we still need to deal with: vendor lock-in. 

‍

For example, how do you make sure that AWS is the best option for your application? You built a quick solution for your client but after a while, you realize that for whatever reason, it turns out Azure is a better fit for your use case, how are you going to migrate it?

‍

Flexibility

‍

What we want is more flexibility to move our apps from one cloud to another. For example, we’d like to change our current provider because of technical or management reasons, like costs, contracts, etc.

‍

Designing portable applications has become more important than ever.

‍

Kubernetes for example has become a big example regarding flexibility, allowing developers to deploy their applications not only on their local environment but also on any major cloud provider.

‍

Still, that only means that you can start and update your application on the cloud provider you choose, but as we introduce complexity and our app and data grow, it will be exponentially harder to switch from one provider to another:

‍

• Services: Depending on your service/s this could become really painful (mostly for microservices).
  ‍
• Data: Probably the hardest part. You’ll need to match data formats with other providers’ services, which may include writing your own scripts and shutting down your application for a while. If you want to do it live, be ready to build crazy synchronization scripts to do this.
  ‍
• Permissions and networking: They have to be reconfigured on the target provider. Also, you should map your services again with private cloud subnets and align everything together to match the same networks and policies, which isn’t a piece of cake at all.

‍

But what if all of these steps were done smoothly? Would this be the next step on multi-cloud? From our side, we believe it is, and it’s what we like to call effective multi-cloud. 

‍

Effective multi-cloud applications

‍

Having tools that really make this effective multi-cloud approach work will be the key to properly manage your cloud applications and infrastructure in the future (without headaches, of course). That’s what we’ve been trying to do with Booster Framework.

‍

With Booster Framework, you can develop your own application by focusing only on business logic, while forgetting about AWS, Azure, GCP, or even Kubernetes deployments, that’s done for you. You just need one command to deploy your application and you’ll get an API to start working with:

‍

‍boost deploy -e gcp

‍

This is currently a reality, but we love challenges and we’re now going deeper and turning this effective multi-cloud promise into reality. Yes, it’s awesome to deploy your application anywhere, but imagine avoiding vendor lock-in, all from the same place, with a single CLI command.

‍

Effective multi-cloud solutions using Booster Framework are exciting, and one of the most beautiful things about it is the built-in opinionated architecture. For example, with Booster Framework, you have the whole event-sourcing architecture already done via serverless (AWS, Azure) or the container’s way (Kubernetes), it’s up to you.

‍

Opinionated architectures on multi-cloud

‍

With Booster Framework, we’re aiming at packing architectures so you have to worry about the few things as possible, and just focus on writing your code. Forget about deciding which service to use, how to connect them, which permissions you should provide, scalability, API management, and a long etcetera. If you need more customization, you can use rockets! (aka plugins).

‍

The thing about opinionated architectures is that they solve all the common headaches while fully dealing with a concrete use case. For example, we could build a Booster Framework rocket that would be just a GraphQL API + document database, while getting everything managed by the rocket (backups, encryption, scalability, triggers to external services…). That way, a developer could use our rocket as it were a complete product, and move it between cloud providers if necessary.

‍

It’s not the same if you just try to move “raw architecture” (no architecture pattern, just services joined), because when moving to another provider, you have to manually select which services suit best your needs, and reconfigure everything. This is one of the big advantages of opinionated architectures, that they work as a whole from the developer’s perspective, and not as mixed individual services.

We really think that having an effective multi-cloud with opinionated architectures out of the box will highly increase the developer’s experience.

We’d also like to know your opinion regarding this topic, so don’t hesitate to join our discord server. See you there!