Sergey Nivens - Fotolia
Plan ahead for app portability in multi-cloud deployments
For dev teams who work primarily with AWS, multi-cloud presents some challenges. Explore these ways to ensure app portability and whether that flexibility is worth the effort.
In a bid to avoid lock-in, companies can architect applications to work across public clouds, but that approach isn't without its challenges.
Developers often choose the simplest route when they first build and design an application prototype. This provides valuable feedback before actual implementation, and with cloud computing, developers can take an app from a prototype to a web-scale application in a short period of time. But in those early stages, developers don't always think about specific services that might lock them into a particular cloud vendor, so they're left scrambling for a better way to design systems when issues arise.
Alternatively, those who want to design early on for multi-cloud deployments can struggle to find a direct replacement for a vendor-specific service on other cloud platforms. And if developers get pigeonholed into services that support multi-cloud capabilities, they could lose key functionality that makes cloud computing agile.
For example, if a company tells developers it can't use DynamoDB because it's AWS-only, it will need an operations team just to deploy and scale a database like MongoDB or MySQL. Chances are that company also wants to run containers for portability, but not with AWS-specific Docker functionality from Elastic Container Service or Fargate. So, it also needs a team dedicated to Kubernetes management. This complicated management structure can significantly slow down application development.
It's typically better to get an application out the door quickly and adapt later, but it's still important to keep certain things in mind at the start of the development process. For example, it's OK to use DynamoDB but handle all database access through an abstraction layer, even if it's built for specific use cases. It will prevent headaches if changes are required and the need arises for multi-cloud deployments.
For AWS teams who want to run containers, they can use Fargate but have a Dockerfile that can be built locally for testing, too. Again, ensure it's possible to deploy to another cloud provider, if necessary.
Framework decisions for multi-cloud deployments
Various frameworks and abstraction layers, including Serverless Framework and FaaSlang for serverless deployments, support multi-cloud. However, developers still need to customize applications to support each cloud separately -- just like with any application that runs on multiple OSes. Google Cloud, Microsoft Azure and AWS all support some form of function as a service, but all of them are slightly different in how they handle the execution and return of results.
An abstraction layer can ensure that functions run the same basic code base, but developers still need to manage how those functions uniquely connect to a database, based on where the actual code runs. Additionally, while Amazon API Gateway can execute Lambda functions on AWS, there's no equivalent on Google Cloud or Azure, so it might require a third-party vendor and service.
A multi-cloud example
At Cannabiz Media, we recently used Google Cloud's Geocoding API to convert street addresses into latitude and longitude coordinates to support location-based searching. Until June 11, 2018, Google allowed developers to make 2,500 Geocoding API calls per day for free. Additional requests over that limit would cost developers about $0.50 per 1,000 records over the free limit. Since then, Google has removed the free tier and now provides a $200 per month bill credit but also increased the cost per 1,000 API calls to $5 -- a 10X increase. Google made 18 separate price increases for the Maps and Geocoding APIs prior to that change.
Fortunately, we designed our application architecture to have one microservice -- a Lambda function -- that uses the Geocoding API. This enables us to swap out the one function that hits the Geocoding API and plug in a replacement API from another vendor (we chose the Algolia Places API). It doesn't matter to the rest of the application where the geolocation information comes from, and our geocoding microservice doesn't require any Google-specific features. The API swap simply requires a rewrite of that one geocoding microservice.
Similarly, both Google and Amazon provide AI services. If a development team uses one of these services, it should isolate the microservice that accesses one of these service's APIs from the remainder of the application. This enables a more seamless switch from one cloud provider to another in multi-cloud deployments.
