After digging through the details of the hottest new technology, have you immediately thought “we need to start using this tomorrow!”? This a common pitfall I see often. Buzzwords get tossed around so frequently that you feel that you are doing things the wrong way.
Let’s take Netflix as an example. Netflix is ubiquitously known as the company that made micro-service architecture popular (or better yet, Adrian Cockroft). Netflix’s goal of bringing streaming content consisted of lot of different services but needed an adjunct way of increasing the speed at which services can be updated. Amazon’s Jeff Besos is quoted with the API mandate saying “All teams will henceforth expose their data and functionality through service interfaces.” This was done to allow any BU, from marketing to e-commerce, to communicate and collect data over these APIs and make that data externally available. However, take a step back and think about what these companies are doing. Yes, they are pinnacles of modern technology advancement and software application architecture, but one is a streaming movie service and the other is a shopping cart (2002 is when this mandate came out). If my bank has externally facing APIs that only use basic auth, I’m finding a new bank. That’s a constraint.
What about your business? Most enterprises have roots so deep it is difficult, if not impossible, to lift and shift.
If I worked for a big five accounting firm, which have been around for 100+ years, I probably have an AS/400 or massive Oracle database with customer account records. This is an example of a data constraint. Greenfield deployments will typically go with a NoSQL flavor because they can afford to start digesting data very quickly and get the benefits NoSQL brings to the table. But, correct me if I’m wrong, I don’t know of a NoSQL database that has been able to consume 20+ years worth of data (because there hasn’t been one in existence for that long). That scale hasn’t been tested and when your greenfield deployment starts getting really large, the growing pains will come along with it. This puts a constraint on the ability to simplify and unify product sets across the organization. New technology tied with your existing infrastructure and large amounts of data is a big constraint on being able to move fast and adopt new tech.
Facebook and Twitter are easily the best examples of scale. Both companies are performing technological miracles that cover everything from compute, storage, networking, programming, monitoring, messaging, data analytics and more. The best part is that both of these companies have contributed their software as open source projects. All of this combined provides all the tools necessary to run a non-critical business. Yes, I said it, non-critical. If Twitter lost 24 hours of data, the whole world will know about it. There will be post-mortems and more articles on Hacker News than you could ever imagine. At the end of the day, all that was really lost is 98% nonsense talk about celebrity gossip and 2% of tweets that didn’t say “#cashmeoutside”. The point I’m trying to make is that even though all these great companies are taking their internal IT tools and making them available to you, it doesn’t mean that you can or should run your IT department like them. Your constraints aren’t theirs. You don’t have the scaling issues or the need to port your existing code to a javascript framework that can support 2 Million requests per second.
This leads to a thought on containers and the battling ecosystem. It’s not hard to see that Kubernetes has a lot of steam behind it. If this were the Kentucky Derby, everyone is betting the 2:1 odds on this horse. It has a lineage at Google, which immediately gives it clout because it’s Google and they don’t need money, just as if the bloodline comes from Secretariat and my horse trainer was Bob Baffert (only horse racing junkies will know about this guy). The 'jockey' in this example is Tim Hockin and his 'pedigree' is demonstrated in his impressive resume of wins. And they have the home field advantage because this is the container space and they have been doing this at scale for a very long time. Why would you possibly look at something else?! I can give you a reason, your constraints aren’t Google’s constraints.
I had the opportunity to listen to a company who used Docker Swarm Mode to create a cluster for their application. They chose Docker Swarm Mode because it was simple. There wasn’t a huge learning curve for the concept of pods and YAML deployments, there didn’t need to be a dedicated master node, and, for their purpose, the built-in service discovery and load balancing got the job done. Their constraints for building this service made sense because they wanted to create isolated clusters for dedicated tasks.
I can’t remember if it was in IT or in my first home remodel when I heard the phrase “use the right tool for the job”. This is still going to hold true for a foreseeable future with containers. Evaluate your constraints. What is the task you want to accomplish and leaves you with operational simplicity, a model of standardization, and room to grow. Does this make sense for my business? If I’m in oil & gas, big banking, or retail then I need to evaluate the decisions related to minimizing exposure and what container technology is solving the right problems for me.
The idea for this post is attributed to Corey Quinn during his talk at Scale15x “Don't You Know Who I Am?! (The Dangers of Celebrity in Tech)”. I encourage you to watch it below