Jiří Krám

Vendor lock is the result of out date or incorrect architectural principles and standards. If you got to a vendor lock it means you did something wrong. Great example is Salesforce, back in days it was very common build a lot business applications in Salesforce platform. It was easy to design, build, deploy and use. But Salesforce platform has lot limitations like API limits on daily API calls and more. Hence many Salesforce instances grew to highly complicated spaghetti with a lots of customisation and propriety code. Unlike other apps you build in Java you cannot migrate this mess to anywhere else because only infrastructure where Salesforce can run is Salesforce. Obviously vendor lock here is unsolvable you have rewrite whole app.

Indeed, working from home is about your ability to build functional office that allow you to gain not just same productivity like in your office in the company. Home office has main advantage when for example work a lot remote. There is simply no productivity gain travel to office where you will spend day with headphones in open space. Main thing happening there people disturb each other. For example, I know about myself I am loud speaker (and when I get excited or angry) I like to speak loud. Also I love combining work with exercise. So my most favourite set up is very large widescreen display with high resolution, desk with electric motor with ability to change height of the desk, I love standing desk and great headphone so I can walk.

Multi-cloud is the main principle every good architect should have in mind. Cloud now days is primarily about flexibility. Great example can be Kubernetes. It really doesn't matter where you run containers. Every cloud infrastructure, Azure, AWS, OCI, GCP, and Openshift has the ability to run containers. This, however, requires updating architecture thinking, usually it comes with updating architecture standards. So that, there is no vendor lock. Smart IT teams work this way, days of cloud walled gardens are yesteryears song. Name of the game is flexibility which means be able to deploy workloads to any cloud or edge anywhere.

Be smart in your cloud strategy. Many developers will try to lead you stray by preaching some gospel like: Oh Salesforce is the best because you will be Trailblazer (meaning you get sticker with bear on your laptop and can make selfie with dancing elephant). What they are really saying Salesforce is only thing they know so you must use it. But it’s wrong strategy you basically pay premium for license (priced as per user / month and you lock yourself to 5 years commitment). Smarter approach is develop cloud agnostic workloads. Then you wouldn’t care where you run AWS, Azure, OCi, GCP and you could also move between then as easy. Now with Gen AI deployment can be fully automated regardless cloud platform. Cloud vendor lock is dead.

Be crystal clear why you are using each cloud way you use it. Here’s an example. You have been traditionally using all workloads on AWS been dependent on price of EC2 instances. Sure you can try different AMIs and play with auto scaling and what not. But what you can find out that many of your workloads are by design multi cloud, it simply doesn’t matter where it runs. Hence smart IT organisations has vendor agnostic workloads. Then you work with cloud VMs same as you would work with physical computers Dell, HP, Lenovo doesn’t matter you just run workload. With cloud it’s the same. You create an image and than run whatever cloud AWS, GCP, OCI, Azure has best performance which is usually shown in test.

No matter what type of cloud computing project you are embarking on, you need to have a value realisation strategy. Why? Because if you connect value you either bring or prevent losing it for organisation, it will get support. Here’s why. Commercial organisations in general has three types of objectives: 1) Make money, 2) Save money, 3) Stay out of trouble. Let’s say your solution targets Saving money by reducing AWS bill 40%. Can you quantify it? Sure you can. Then it’s about giving it a try. For example: You keep 90% of workloads on AWS and put 10% on OCI. Then you measure cost efficiency in both. You may find some services runs cheaper in OCI other in AWS. But if you never try you never find out.