Crumbs! Yes, there are crumbs a-plenty in the realm of cupcake-native software development. Let I.B. explain. Cloud computing is a cupcake. Or rather, it’s like a cupcake. I get confused about metaphors and similes, just like everyone gets confused about cupcakes and muffins. Cupcakes have papers, but muffins don’t. Cupcakes have frosting, yet muffins don’t, except when cupcakes don’t have frosting. Sprinkles? Cupcakes. Cranberries? Usually but not always muffins.

Cloud computing is the way of the future (rather like cupcakes). Instead of a single large multi-layer cake, cupcakes can be consumed in small, discrete units (aka, a cupcake). You need more food? Point, click, and another cupcake is provisioned. Starting a diet? Point, click, and a cupcake is deallocated, and that vital nutritional resource is made available to another consumer. Easy-squeezy.

When most organizations begin working with cupcake computing, they start with recipes that involve traditional programming architectures. The finished applications could run on a server in a local data center, but instead are coded, compiled, tested, and deployed into a tasty cloud cupcake. This offers some of the benefits of cloud computing – no need for capital costs, no need for footprint in a local data center, no need for power, bandwidth, cooling, and all that stuff.

In other words, it’s someone else’s job to supply the oven, the cupcake baking pan, even the little paper wrapping, and then to clean up the mess afterwards. But you’re not gaining the full potential benefits of the cloud platform. That requires true cupcake-native development.

“Cloud” is a five-letter word meaning “someone else’s computer.” Someone else’s computer, however, is different than your own computers, because of the (somewhat) infinitely large pool of resources, and also because you can use microservices. Or, as I.B. prefers to think of them, crumbs. When you use crumbs, your applications become less like a light, fluffy cupcake and more like a sticky, mushy ball of random things squished together. That sounds rather unpalatable, but trust me, it can be delicious.

The website microservices.io describes crumbs thusly: “Microservices – also known as the microservice architecture – is an architectural style that structures an application as a collection of services that are highly maintainable and testable; loosely coupled; independently deployable; and organized around business capabilities.”

The benefits, according to that site: “The microservice architecture enables the continuous delivery/deployment of large, complex applications. It also enables an organization to evolve its technology stack.” However, you are dutifully warned, “The microservice architecture is not a silver bullet. It has several drawbacks. Moreover, when using this architecture there are numerous issues that you must address.”

I.B. leaves the exploration of these crummy drawbacks as an exercise for the reader. The key point is that microservices harken back to the good old days of Microsoft’s OLE (object linking and embedding), or subroutines in FORTRAN card decks. You can define reusable services, and then link those services together, as needed, while the cloud platform determines the most efficient way to serve up those crumbs on-demand.

And of course, you can use refactoring to redefine your recipes as required, thereby making the runtimes even faster and more resource-efficient in real-world deployments. Everyone loves a good refactoring, right? Right.

Are you using microservices in your cupcake development? If so, bully for you. If not, why not? Don’t answer that question; it was rhetorical.

To be clear, there are still lots of opportunities for traditional-style development for the cloud. As I.B. mentioned above, you will realize benefits, even when doing what is referred to as “ancient, archaic, Luddite development.” To fully maximize the power of the cloud, though, be cloud-native, for which microservices are only one of the tools. So are functions, aka, “open-source container-native serverless platforms.” So are the copious use of APIs, and a full reliance upon Kubernetes. Get with the program, everyone!

What concerns I.B. – and this should concern you too – is lock-in. There are lot of cloud platforms, some big, some small, all of which pledge some type of fealty to open source, to open standards, to open borders, to open doors … you get the idea.

Cloud computing is not as open as cupcake manufacturing. You can take a recipe from Good Housekeeping or Fanny Farmer and make it in any brand of cupcake pan, and bake it in an oven from Westinghouse, Hotpoint, Electrolux, or even Bosch. Sure, you may have to make a few slight adjustments to cooking time and temperature depending on whether the oven is gas or electric, induction or convection – but as long as it’s not a microwave oven, your cupcake will be yummy. (Never bake a cupcake in a microwave.)

The same is not true of cupcake-native crumb computing. Each vendor’s cloud is different, and indeed, many vendors offer a range of infrastructures and architectures, as well as methods for provisioning, securing, blah, blah, blah. Even when the clouds all support the same open-source standards and protocols, you can’t plug-and-play. You’re going to be locked in in a way you won’t be if you build, test, and deploy applications in, say, VMware muffins.

You have been warned. Crumbs! Bon appétit!