Sashank Purighalla
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:
- 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.
This is mainly because the choice of services, categories and integrated tools from cloud providers is overwhelming. For example:
- Azure has services under categories like AI and machine learning, analytics, compute, containers, databases and DevOps. Each of these categories has dozens of unique, Azure-specific services with certain implementations and functionality.
- AWS’s services are split into similar categories like compute, analytics, database, machine learning, storage and networking. But with more than 238 services, its offerings are bound to be different from Azure’s in terms of cost, usage and the integration involved.
That’s why founders and CEOs should determine what they want the outcome of their cloud applications to be. Is it about performance, reliability or lowering costs? Would your team be able to maintain whatever tool you choose in terms of costs and security?
Cost is often a major obstacle for founders who want cloud computing. Startups with fewer than 100 employees spend an average of 52% of their budgets on infrastructure, according to a survey by DigitalOcean.
Let’s imagine you are looking for logging tools (for each layer of the cloud), with cost-cutting as the desired outcome. As there are dozens of solutions available for optimization, aggregation or visualization, you must think about the capabilities of the different tools and understand the trade-offs.
Let’s break down three different logging options:
- Azure Monitor works on top of the Azure Log Analytics Workspace and can integrate with all managed services offered by Azure.
- Datadog is a paid third-party service that integrates with Azure Monitor and Azure Event Hubs, a streaming data pipeline.
- Splunk is a paid third-party service available as a SaaS solution in Azure’s marketplace.
It is more cost-effective to go for a solution that works independently from Azure Log Analytics–Azure Monitor combo as much as technically possible. But when selecting a third-party Log Analytics paid solution, it is critical to understand from which layer it ingests the log data.
Azure Monitor can become a major contributor to monthly cloud bills if it’s not explicitly configured per data source and data source type. Note that third-party Log Analytics solutions that integrate with Azure Monitor act upon a data pipeline. This causes a data export cost on the Azure side of billing, whereas the user mostly looks at the data ingestion cost billed by the third party. You definitely want to know all this in advance to avoid added costs.
Be prepared to update as business needs change
Startups should realize that every decision with cloud infrastructure has a short life span — the cloud needs constant upkeep and adjustment. The stage of your startup will dictate the evolution of tools, as the combinations will change dramatically over time as your business scales.
One of our customers built their DevOps pipelines using Jenkins, an open source and free automation server to build, test and deploy software. This would have been fine while they remained small. But as the need to scale this implementation arose, the startup realized that Jenkins was not scalable, as it could not run as a clustered implementation.
The company tried vertical scaling with Jenkins, and the developers quickly realized it had reached its physical limits. Then one engineer thought to containerize Jenkins and put it on Kubernetes, but Jenkins natively does not work in state-less mode.
The next option was to look at alternatives built for scale: GitHub Actions, GitLab, Azure DevOps, and AWS CodePipeline, all with many other tools to consider.
More material considerations beyond tooling choices include time to implement, who to train or onboard, and how to deal with customer-facing priorities, alongside “urgent” back-end operational tech to become scalable.
Use a combination of tools for successful cloud deployment
We’ve witnessed a shift in how software is designed: from monolithic applications running on virtual machines to microservices and container-based infrastructures.
In turn, that means startups and their developers have to view cloud solutions tools in combinations that will accomplish an outcome rather than individual siloes dedicated to specific functions. Perfect one-to-one matches of cloud infrastructure tools don’t exist; it is more like a Venn diagram.
If we stick with the logging example, a whole combination of different tool sets can get the same successful outcome, including the ability to associate and persist queries with a visual representation of the data stream and create alerts on data ranges.
The same can be said if you want to build an application in Java on Linux and deploy that on Kubernetes. The tool set required will be very different from what a developer needs to build and deploy an application on an individual Linux machine with a simple CD pipeline. Learning how all these tools interact with each other in combinations is essential for long-term maintenance.
Analysis paralysis is completely warranted, as there are so many subspecialties within cloud operations. Companies must consider storage services, authentication providers, network security layers, and other managed or hosted virtualized services like load balancers, databases, and container orchestrators.
To navigate this crowded cloud infrastructure market, startups should be aware of using tools in combination, their budget, their security and compliance needs, and the knowledge their team or developers have.
Comment