BARE METAL-SERVICE STACK AKA nOs

I have been wondering lately about how we are going micro in designing our services out there on the cloud and to what extent we can optimize the performance without making new security risks.

I am not sure product makers become realized how much it is hard to go micro at the early stage and that’s why they must do it from the start. I will explain why later.

TLDR: can skip to SEC-4.

MICRO IS GOOD

Yes, we used to start writing our service business logic models in some single monolithic app-stacks back in the days. That was neat, quick and doesn’t need big and experienced teams instead we can bootstrap a service without any development blockade. Hire one or two and start your development, mentor your team in the process. They grow, you grow.

But then again, the service grows too fast. Business demands hype up to sky and your team started complaining about how hard it is for them to keep up with new business demands. On the other hand , business is doing great but development and service quality wouldn’t keep up and users not happy ✋.

Now and then your monolithic stack wouldn’t let your managers producing just a single portion of their features instead they have to wait for others inline or by line.

What micro and a few human conventions would give you is a free passage from release traffic and make your user happy. That’s why if you plan to run your product for at least a decade or two, you go micro. Well, it is up to you and your resources frankly. But making users not happy is not good for your existence aka your business.

STACKS

The industry is not always Agile-oriented which means that you don’t have to say agile just because some teams have used it successfully.

That’s also true for the choice you would make when it comes to choosing your stacks. Some would say GO is awesome backed by Google. Some say PHP will never die because Facebook uses it. Your users don’t really care about how your technology is cool anyway. So you don’t have to be COOL.

You just got to be functional and realistic when it comes to your specific choice. Please read less about how things are going up-hill by other teams instead talk with your peers and see which one they are comfortable with. After all, they are the ones who will help you build your product, not some twitter handles popping up under a tweet you made earlier this evening.

HOW MICRO?

People think breaking up API calls between inter-services is micro. It is partially true but what you truly want to archive is independent non-persistent service components.

The persistent layer usually databases and asset stores can be curated in a conventional and independent way to hook up with the nearest upper layer. But the service workers should be working on independent runtime and configuration levels and that way we can bring down service while giving the other one in return.

I think Instagram and GitHub does that when it comes to their notification and messaging systems. People don’t care about notifications as long as their pull-requests and pushes are working right?

Now we can go hardware-level micro-services.

BARE METAL

With today’s engineering talents and resources, people are starting to look beyond what is underlying our services. There are already several appliances for a specific purpose in VOIP and networking industry.

But why not in our cloud services?

Nix took the first daring step and questions everything from ground-up perspectives about how we design cloud services. They took the first shot of stripping down Linux to a functional level and made atomic upgrades and roll-back at OS level possible.

So check out the NIX project and play it with your own hands a day or two. You will see how much it is convenient to have their offerings in your stacks. Nix does talk to metal or you can just simply configure in your virtualization environment like XEN, ESXi as a node.

But then again and just recently, I spotted a new project, which is probably very experimental and the main purpose of this post, to make myself remember everything about my evening read, is CLIVE.

So CLIVE compiled your stack [ currently they support GO I guess ] along with other dependencies and run it directly on machines.

Inter-service calls happen over channels and those channels are bridged over network or PIPEs [ IO ] as you wish. Obviously your query call would only want to talk to PIPEs aka IO while your service routes would love to be bridged in a network interface. Everything is yours doing.

Now we can go to BAREMETAL-micro!

Thanks