The promise of lower hardware costs has spurred startups to migrate services to the cloud, but many teams were unsure how to do this efficiently or cost-effectively. Developers at startups thought they could maintain multiple application code bases that work independently with each cloud provider.
Now they’ve realized it is too time-consuming to manage, and there’s no glory in trying to be everything to everyone.
Deploying cloud infrastructure also involves analyzing tools and software solutions, like application monitoring and activity logging, leading many developers to suffer from analysis paralysis. That’s why cloud monogamy is the generally accepted operating principle for startups. But not every company has the luxury to operate within those confines indefinitely.
Realistically, it’s essential to analyze the tools available before you decide on a cloud infrastructure provider to keep application maturity and running costs in check.
You either need:
- Experienced developers to maintain architectural integrity, maintainability and licensing considerations, or
- A cloud platform built to adapt to the changing landscape and build, migrate and manage cloud applications.
Until you get those, here are some best practices for getting started. Let’s take a look at the issues startups face with the cloud, how to define the outcome of your cloud applications, how to know when your cloud infrastructure needs updating, and how to use a combination of tools.
Analyze where you are and learn about startup cloud struggles
When it comes to cloud infrastructure, there are two levels for startups:
It’s essential to analyze the tools available before you decide on a cloud infrastructure provider to keep application maturity and running costs in check.
- Early-stage startups building their first minimum viable product. These companies want to deploy minimum cloud computing to reduce infrastructure costs and technical decisions so they can focus on product and market strategy.
- Startups with products that have traction. These companies are worried about the future of their cloud infrastructure in terms of security, scalability and maintainability. However, they are not large enough to hire a team of experts.
Founders and decision-makers at both levels struggle with the depth of technical expertise required to manage cloud computing. For example, I was approached by a midmarket startup that had built its solution in AWS, but its only focus was getting it all up and running (level 1). Therefore, it had accumulated technical debt, and the cloud architecture was complex, with hundreds of servers, several dozen unique services, third-party tools, partial logging, and poorly implemented service meshing.
Then this company signed a new customer based in China who insisted on having their entire cloud solution on Azure-China, a subset of Azure (level 2). The company was clueless in this new environment.
Building parallel solutions that have parity on different cloud providers can be costly and require enormous effort. But the alternative for this company was losing an important contract. They had no choice.
To duplicate and readjust code to work on two disparate environments, the company’s developers could have faced further analysis paralysis in attempting to learn all the implementations, services and considerations involved. That’s why startups need platforms to create cloud-agnostic architecture, write code, and automate deployments to their target cloud(s) while performing relevant testing and security validations.
Work out the outcome you want to deliver
Many startups follow a “build and fix model” for cloud infrastructure. That’s because startup developers pick the first tool they see and then the company is tied down (due to licenses or tight coupling). Or they take someone’s recommendation, which may not be optimal in terms of how it interacts with other cloud layers. Then the lack of proper analysis and experimentation of available tools leads to awkward trade-offs and undesirable business blockages.
Credit: Source link
Comments are closed.