Kubernetes is, of course, one of the more exciting infrastructure initiatives to have come to light over the past several years. Kubernetes is, as most people around the space will realize, directly descendent from Borg, the system Google uses internally to manage its own infrastructure. But outside of Google (and, after all, Borg isn’t exactly a like-for-like case study for Kubernetes), there is a dearth of good chunky Kubernetes case studies. That’s hardly surprising, it is, after all, still pretty early in Kubernetes existence, but this lack of case studies does put a dampener on things somewhat.
It is for this reason that I was pleased to hear of Software Motor Company (SMC) a company intent on bringing the IoT to electric motors. SMC’s value proposition is that its motors are connected directly to the cloud meaning that SMC has full information into the real-world operation of its kit. SMC can, therefore, predict equipment failure before it happens.
But doing that introduces some challenges and SMC points to the example of a pharmaceutical facility that needs to keep room temperature and air pressure within a very specific range. But with constant data transfers, there is high risk. If there’s some indicator that pressure is destabilizing at a pharmaceutical customer site, SMC wants to be able to quickly react to that. If data stores are down, SMC cannot take the right actions and the pharmaceutical company might have to throw out a multimillion-dollar batch of drugs that they’re creating – data availability is key.
The folks at Portworx provide products to help organizations do what they need to do in order to run containers in production and they sat down with Federico Nusymowicz from SMC to find out about their use case.
First up some more information about SMC. Founded in 2013, SMC wants to do to motors what LEDs have done to lighting. As they put it, LEDs are basically the peak of energy efficiency when it comes to lighting. In comparison, the electric motor has seen little innovation over the past 40 years. Induction motors, which drive the air conditioning in buildings, golf carts, condensers in refrigerators are very inefficient in terms of energy consumption. Most run at a fixed speed, which means they’re consuming 100% electricity even when they only need 20% to generate the right amount of torque.
The SMC motor solves these problems and delivers related benefits. First, the SMC motor turns more electricity into mechanical energy, the way an LED converts more electrical energy into light. In addition, the motor intelligently consumes the exact amount of energy required to drive connected equipment. The motor is also more reliable than induction motors – the basic design that has been used in mines and nuclear plants for decades.
And this is where the tech story comes in. SMC motors are more efficient at a fundamental level due to their core architecture but also because of the intelligent controls attached to it. Because the SMC motor is connected to the cloud, the company has full data on its operation.
And so, on to the Kubernetes aspects of the story, SMC is using containers as the packaging mechanism for their microservices. These containers are deployed and managed by the Kubernetes scheduler. Currently, SMC runs Kubernetes on AWS. But the choice of Kubernetes was very specifically made with one eye looking for application portability.
As for the Portworx angle, SMC had some key challenges to overcome in order to run databases in containers. According to the company, the first challenge was service availability. It’s pretty common that a node will go down for any number of reasons, and they don’t want to lose service when this happens. SMC can’t afford to be losing data from motors because that is critical information.
Back to the pharmaceutical example, if there’s some indicator that pressure is destabilizing at a customer site, SMC wants to be able to quickly react to that. If their data stores are down, they cannot take the right actions, and if they don’t react, the pharmaceutical company might have to throw out a multimillion-dollar batch of drugs that they’re creating. High availability, therefore, is the first and foremost requirement.
After high availability, the next requirement was durability of system data. There are any number of reasons data can get corrupted. It is possible to address durability fairly well with backups and replication – which some databases like Cassandra provide out of the box – but replication becomes more difficult when you’re writing your own stateful applications. According to Nusymowicz, that was another pretty cool thing about Portworx; replication works out of the box regardless of which data service sits on top.
Weighing up the options to solve the availability and persistence issues
SMC is currently running on AWS EBS albeit not directly. The company actually runs Portworx on top of EBS for functional reasons. Disaster recovery is always a goal of critical systems, and if SMC wants to do disaster recovery in an automated way with EBS, they would have to figure out a way to reliably detach the volume from the failing node, and then reattach it to a different node. That gets messy since EBS volumes end up getting stuck.
Nusymowicz explains this layered approach towards data, saying that:
If we have a simple application pumping data into one EBS volume, great. EBS failures are rare and likely this would work fine. But when you operate at scale, you have to plan for failure. And that’s what I like about Portworx. You can replicate all your data to other volumes automatically, so even if one volume fails, it’s no big deal because you have that data in two other places. And the replication can actually happen across availability zones as well.
Advice for organizations thinking about running stateful services on Kubernetes
Nusymowicz advises organizations looking to traverse a similar journey to SMC to start by asking questions about why they’re thinking about using microservices and containers. As he suggests:
If you don’t have complex requirements or need to keep control over your data, there are some great hosted data services that you can use. Assuming the person has good reason to run containers, such as the reasons I gave about privacy, control and portability, I would urge them to think very carefully about what data storage to use and to think critically about where they were going to run these services and how the data gets backed up, how to keep services highly available, protected, etc.
MyPOV
Some interesting lessons there from the coalface – worth reading for anyone who is considering a similar path.
