I received a note from Protego Labs’ vice president of marketing about Check Point Software acquiring Protego. We see a fair number of acquisition announcements, and usually don’t write about them–though we read them and stay abreast of industry happenings.
I used to follow Check Point, and haven’t looked into what they’re doing in a while, so I followed through links to both organizations and looked at their products.
I found myself becoming the wizard that some call Tim. But instead of “What is your name? What is your quest? What is your favorite color?” I was looking into “Where is your site? What are your products? What value do you add?” My beard is kept trimmed, more along the lines of a knight’s, so it makes sense I would ask different questions. As long as I’m not spouting “It’s just a flesh wound,” I figure I’m doing okay.
First off, this merger makes sense. Protego does it for serverless and Check Point is doing their best to be where your code is running. Indeed, Protego probably needed a merger of some kind because all they do is serverless. Check Point’s Cloud Guard Dome 9, by contrast, will protect access rights and data for serverless, but doesn’t do what Protego does–keep an eye on the code. So this is a good fit.
But it once again brings to light an interesting issue as you move things from DC to cloud A to cloud B to serverless. Where are your support functions? Networking, security, storage…These things need to be where the code is, but architectural options are more than they’ve been for decades. And the architectures are largely incompatible. Consider network functions for a physical-server based DC versus a VM DC, versus a Container DC, versus Cloud…You get the idea. The array of functionality and where it runs is different. Different in implementation and different in maintenance.
This was a problem I (and others) pointed out when cloud started taking off: more work for ops, even if some of it is automated. Turns out ops, storage management and security all have more work, because all of those items are handled differently in the different architectures. And Protego had to focus on one to get it right, meaning they needed some kind of merger in the long run.
So do you. Adding more and more work to ops–be it DevOps or traditional ops–is not the answer. A plan for standardizing is necessary.
That is one of the big promises of containers, in my opinion. Not only are they more agile and easier to use in a DevOps environment, they are relatively standardized. Ops will still have more work if you’ve got apps in several of those architectures, but containers obfuscate some of the differences and allow standardized networking within the pod/node/group, for example.
Some functionality just doesn’t fit into containers–you still need a physical network in the DC, or to configure the virtual network in a VPC to get traffic to/from your containers–but much of it does fit. Once at the pod/group, networking is virtual and the same regardless of where the containers are running. Which reduces overhead while making changes easier. The same is true for security, and increasingly for storage.
There are great companies out there tackling these issues, and I’ll look at them on occasion. Right now, I know my former employer F5 Networks is working to solve the networking services/performance/security issues, and taking advantage of NGINX to handle some parts the core org traditionally hasn’t addressed. There are other companies, I just hear about that one more because I am still very close to some F5ers.
It is worth planning for and certainly worth looking into more portable options, anything that lightens the load and keeps your great apps running. Keep kicking rear and spinning up apps.
And don’t call me Tim.
Dhrumit Shukla has been working as Business Development Manager in a software development company named 
