How should we deal with the 'vendor lock-in' problem per customer of cloud service?



The spread of cloud services, such as Amazon Web Services (AWS) , Microsoft Azure , and Google Cloud Platform , has made it possible to deploy a web business without having its own server. Meanwhile, Vacation Tracker, an app vendor that can easily manage team vacations on Slack, explains vendor lock-in for cloud services.

Fighting vendor lock-in and designing testable serverless apps using hexagonal architecture-Vacation Tracker
https://vacationtracker.io/blog/big-bad-serverless-vendor-lock-in/

'Vendor lock-in' means that a user can not shift to another vendor without paying the cost for switching as a result of relying on a specific vendor (manufacturer).

For example, suppose a user borrows a server. Users call this server a 'cloud' and apply it to storage, computing, machine learning, and more. The server lender has a large number of other servers and users, and the user charges only for using the server.



However, as the users embrace cloud services and implement them in their own business logic, it is possible for the server lender to raise usage fees.



Suppose you have another lender with a lot of servers. The cloud service provided by this lender can be applied to servers in various applications such as computing, storage and machine learning. The new cloud service is cheaper than the cloud service you are using now, and the user-developed apps and services may also work.



Then, if it is solved if you migrate cloud services, things are not so easy. Naturally, the operating environment is different between the conventional cloud service and the new cloud service, so it is necessary to adjust and test along with the environment transition in order to migrate and operate as usual. In addition, the response made on an ad hoc basis to clear up the problems encountered up to now may stand in the way as a major obstacle when migrating services. As a result of considering the switching cost for service migration, it is often the case that it is judged that 'even if usage fees are rising, it is better to operate as before.'



However, if there is a problem with the cloud service itself, if the migration remains difficult, the application itself may eventually stop working.

Vendor lock-in tends to think that it is not possible to change the vendor at all if it gets stuck because of the word “Lock in”, but this is merely a problem of switching cost, Vacation Tracker points out . In the article ' Switching Costs and Lock-In ', Mark Schwartz, an enterprise strategist at Amazon Web Services (AWS), also believes that the term 'lock-in' is misleading. “The cost of switching has been in the history of IT so far. If you try to change the platform or vendor later, you will incur the cost of switching. For example, select Java and then Node. Migrating to .js costs money. '

Vacation Tracker argues that solving the vendor lock-in problem of cloud services is directly related to 'how can we keep the switching cost low'. And, as an example of a method to keep switching cost low, the design which adopted ' hexagonal architecture ' is introduced.

The hexagonal architecture is 'the database and external service depend indirectly on the application through an adapter', and the design concept is that the application itself with business logic does not depend anywhere. Vacation Tracker says that adopting hexagonal architecture enables application development that does not depend on a specific infrastructure.



For example, Vacation Tracker used MongoDB 's repository for unit and integration testing. However, we decided to move to DynamoDB , so we created an adapter called dynamodb-repository.js and called it. This repository has the same interface as MongoDB's. During the migration, we connected the service to two repositories simultaneously and rebuilt. Finally, when the migration is complete, remove MongoDB's integration from the service.



The Vacation Tracker's Vacation Application app was designed as a “testable serverless application using hexagonal architecture”, so the switching costs could be kept low. Vacation Tracker says “To keep switching costs low, you have to think from the planning of the application, and, while updating the application, to avoid the cost of migration that will be needed in the future, We need to consider some good architectural practices and software deployments . '

Related Posts:

in Posted by log1i_yk