Tradeoff: a balance achieved between two desirable but incompatible features; a compromise. Schooling often promotes the idea that there is a right and wrong answer to questions… It does little to prepare us for how many times that there are multiple right answers and no definitive best path forward. In a time where we have unlimited information at our fingertips, you can throw a stone and hit a thousand people with an opinion.
Containers are nearly ubiquitous in software these days. Outside of abstractions like fully managed services (RDS, Dynamo, Cloud SQL), everything engineering teams are responsible for, mostly, land in containers. For many, deciding what platform to run those containers on is a burning question. Choosing the wrong container management solution can be a real headache.
The software engineering world has become a place where compute, storage, and availability have become the cornerstones of scale. As an industry and as individuals, we should stop to take a closer look at scaling the most important of all resources… our people. In this post I’ve modeled a team with 6 engineers, 2 Sr, 3 Mid, and 1 Jr. This team is getting 450 “units” of work done ( where a unit is just some measure of throughput ) per interval (2 months).
I'm Konner, a Strategic Sales Executive here at Cycle.io. With a background rooted in DevOps and CI/CD, I've dedicated over three years to engaging with developers and the DevOps community, consistently learning and gaining insights from each conversation.
Maintaining a consistent environment from development to production is one of those challenges that's always easier said than done. It used to be that a small hiccup—like a version mismatch or a misconfigured setting—could have you scrambling to figure out why everything worked perfectly on your local machine but started falling apart elsewhere.
Greetings! My name is Matt Krauser and I’m a Strategic Sales Executive here at Cycle. After participating in nearly a hundred demos of the platform, I wanted to step back from my day to day grind and share a little about my experience thus far. My goal in writing this is to compare Cycle and Kubernetes, discuss the primary pain points I hear from prospects and K8s users on a daily basis, and explain how Cycle can alleviate these challenges.
The journey to selecting a container platform is a fun and exciting time in any organization. Container technology abstracts away so many problems from cloud 1.0 VM based approach, and puts engineering teams back in the distributed drivers seat. As containers continue to mature and adoption becomes ubiquitous, there are many lessons to learn and ideas to consider before inevitably choosing Cycle. Let's take a look at Cycle alongside the other types of container platforms.
What better motivation to start adopting a technology than the need to completely replace the alternative. From a world driven on limited resources like gas, coal, and oil to wind, hydro, nuclear, geothermal, and solar… we find ourselves, as a species, evolving past a first generation we envisioned as abundant, but turned sparse. Adopting IPv6 networking is another version of this same story.
In the modern web-app space, there’s been a trend going around that I like to describe as “getting back to basics”. It seems as though over the years, the tooling and complexity around building web-apps has gotten more and more complex. In that time, we’ve strayed further from browser primitives into highly abstracted and javascript-heavy solutions to solve problems our browsers solved back in the 90’s.
Multi-cloud seems like an obvious path for most organizations, but what isn’t obvious is how to implement it, especially with a DevOps centric approach. For Cycle users, multi-cloud is just something they do. It’s a native part of the platform and a standardized experience that has led to 70+% of our users consuming infrastructure from more than 1 provider.
