Early technical decisions can help make or break a product. The effort to make the right decisions can be a great unifier between standout engineers and top notch executives
At Cycle we've been obsessing over the nuances of infrastructure automation for years. So far, it's landed us on the G2 grid as a high performer in a category dominated by the goliaths of the cloud world.
Early on, we learned how important it is for organizations to own their own infrastructure. This approach is much different than abstract/serverless architecture, where users are limited to inputs and outputs - but never really get to see whats going on under the hood. The key differences become more apparent when you look closer at the overall pieces that the user retains control of.
A platform that allows you to bring your own infrastructure (BYOI) only requires a basic integration with the provider(s) via some type of key (api, access, project, etc), while the user still retains control over the account from which infrastructure can now be deployed. The platform, Cycle for example, requires the user make no further interaction with that provider other than billing administration or the occasional consoling check to debug a provisioning event.
| Issue | BYOI | Abstraction/Serverless |
|---|---|---|
| Ownership of Data | ||
| Hardware Customization | ||
| Granular Access Controls | ||
| Flexibility Around Disaster Recovery |
Each of these points can affect the decision-making of an organization's executives, engineers, or both. In the next sections, we’ll look at the impact of each point and how it might affect these roles.
Data is the key resource for many organizations. Not owning your infrastructure can mean not having pure baseline control over your data, and for many this is not a viable option.
Developers who work for an organization which owns their underlying infrastructure will be empowered to have more control over recovery in worst case scenarios. Take for example, the idea that the platform you're using goes completely offline. This could be caused by many things, but for brevity let's assume the company just goes out of business and their core services are shut down. A developer with access to the infrastructure that service was running on could go in through the provider’s management layer and remount the disk volume to a new OS, giving them the ability to recover valuable data, which would be impossible in the other case.
Executive teams can use this safeguard as a way to build out their disaster recovery plan and understand that their total risk from a BYOI platform is dramatically less when it comes to data loss, ensuring they are doing everything they can to protect their business from catastrophic loss.
Data may be the new oil, but hardware is the engine that decides how much data your organization can process. With a BYOI solution, you can be confident that you're getting exactly what you want, because you'll be in full control at all times. Take, for instance, server A with 4 vCPUs and 10GB of RAM vs. server B with the same resource allocations.
Server A could have older hardware, causing it to perform at a permanent disadvantage to server B — however, without control over the underlying account it would be hard to prove what hardware your software is really running on.
A developer that's been tasked with implementing an optimization strategy will have a far more difficult time understanding why their benchmarks are coming back with inconsistent scores or running far slower than tests on their local machine. This could be due to the hardware they're running locally being far superior to the hardware of the abstracted service that's trying to optimize revenue by being the middle man in the infrastructure game. With a BYOI solution, the developer can analyze the benchmarks of their software against any number of machines and understand what type of server works best.
The executive team can use these benchmarks to make judgements about the overall architecture of the deployment, unlocking a key advantage in the age of distributed systems. Knowing — and controlling — the exact location, server type, bandwidth, and other core hardware metrics allows for continued optimization and implementation of the organization's cloud strategy.
Throughout this post, we've taken a look at several reasons why an organization that chooses a BYOI platform will have a strategic advantage over those who choose to use an overly abstracted/serverless type service. All of these points really culminate in transparency and insulation.
Transparency includes knowing what you're paying for, what's running your software, where it's located, how much it costs per hour, the bandwidth / networking capabilities and access to the machine. These things shouldn't have to come second when you're building on a platform and for many teams full transparency is the only way forward. Transparency leads to a team that can be truly proactive and also, when needed, reactive. Being able to plan for the worst but make changes for the best is powerful and dynamic in a way that abstracted/serverless software will never reach.
Insulation is the amount of protection you have between your product and the platform you're building on and it comes into play during worst case scenarios. That scenario is played out when a platform either goes offline or is rendered incapable of continuing services (maybe they go out of business).
If your provider goes offline, how would your applications be impacted? In Cycle's case, the user would have almost no interruption of service because their infrastructure is running their core containers, and while they'd be at a disadvantage no longer having access to the portal or being able to run API calls, they'd still be able to recover their data and have users interact with their software.
Make sure to keep these two points in mind when considering how your organization wants to approach infrastructure. While some services abstract away the need to manually interact with infrastructure 99.999% of the time, it's generally in the best interest of the end user to maintain the ownership of the hardware, virtualized or not, that powers your software.
💡 Interested in trying the Cycle platform? Create your account today! Want to drop in and have a chat with the Cycle team? We'd love to have you join our public Cycle Slack community!