Kubernetes is a highly distributed, microservices oriented technology that allows devs to run code at scale. K8S revolutionized cloud infrastructure and made our lives a whole lot easier in many aspects. Developers don’t have to do anything but write code and wrap it in the docker container for K8S to handle. But even its greatest enthusiasts will admit debugging Kubernetes pods is still a pain.
Developing Artificial Intelligence and Machine Learning models comes with many challenges. One of those challenges is understanding why a model acts in a certain way. What’s really happening behind its ‘decision-making’ process? What causes unforeseen behavior in a model? To offer a suitable solution we must first understand the problem. Is it a bug in the code? A structural error within the model itself? Or, perhaps it’s a biased dataset?
“He who controls Dune controls Spice. And he who controls the Spice controls the universe.” It is not hard to see that Frank Herbert’s science fiction classic Dune is a thinly veiled critique of the world’s dependence on Oil. As some people like to quip these days – Data is the new oil. Just like Spice, Data lets you expand your mind and see into the future. But it is also a great addiction.
Remember the good old days of enterprise software? When everything had to be installed on-premises? To install an application, you’d have to set up a big, vertically scalable server. You would then have to execute a single process written in C/C++, Java or .NET. Well, as you know, those days are long gone. Everything has changed with the transition to the cloud and SaaS.
Welcome to the brave new world of developing in the cloud! You’ve heard all about the technical ins-and-outs of setting up a cloud-based microservices development environment and have decided to give it a whirl. Now you need to stock your toolbox with solutions that let you understand what your code is doing, so you know when something’s going wrong and can get accurate feedback as to what it is and how to fix it.
As deployments become more complex and require more moving parts, simulating the full microservice environment on a developer’s laptop becomes really tough. At a certain point, it just can’t be done right and provisioning a cloud-based environment becomes your dev weapon of choice. This may be a less familiar option for devs who are new to microservices. However, it offers many important advantages and (you guessed it!) some significant drawbacks.
— “So what are we going to call this startup?” “I don’t know… Hmm… I guess something dot com or something dot io?” We, humans, are story-driven creatures, and a good story needs good characters. From Odysseus to Sherlock Holmes, from RBG to Daenerys Targaryen to Elon Musk. Good characters come with good names.
In the first part of this series, we discussed how developing with microservices differs from monolith development, and how those differences impact the choice of dev environment. In this second post, we’ll talk about when it’s best to leverage the local environment and the tools that can help.
Over the past few years, whenever the topic of microservices arises, this familiar question also comes up: What is the best approach for developing a few/numerous/countless microservices? In a time-honored tradition, I generally answer with a slew of additional questions: Have you already started developing? How large is the team working on the application? Have they ever developed apps in the cloud?
