Over the last few months, you may have noticed that many of our changelog releases mentioned the release of, and improvements to, Cycle’s native load balancer. While this load balancer still officially remains in beta status, we wanted to begin diving into the details around it a bit more thoroughly: What is it? Why did we build it? How can you use it?
In part 1 of this 2 part blog we looked at some common engineering tradeoffs. But how might someone navigate these tradeoffs and build a model that works for their product? Here are some core concepts that can help along the way.
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.
