It’s not always either or, to often we present IT choices as though they were strictly black and white. Here’s why I think that is, because there are those in the industry that have only worked on the vendor side. This presents such a slanted view of the world. The one thing I have learned from the vendor side is vendors listen to industry analysts to figure out where disruption will come from and they try to skate to the puck. As I have said many times this doesn’t always match up with the maturity of their customer bases. The thing is we are trying to position cloud native apps as bowling alleys and not as buffets. At a bowling alley you are assigned a lane, given specific shoes, and told to pick from one of the various heavy balls. That’s pretty restrictive, when in reality cloud native apps are much more like walking down a Vegas buffet line. You can find just about everything on that table, none of it may be as good as you could get in each cuisines niche restaurant but it’s all serviceable. Cloud native apps are about mixing capabilities and leveraging existing external services to accomplish complex tasks.

This means that some of your services may be sitting in different clouds than your application code. If you are architecting right it’s about multiple clouds coming together from a cost competitive scenario as well as a vendor lock-in avoidance perspective. But it can also mean that hybridity of service applications could be necessary which may even include on-prem.

I was talking to Tyler Britten about this whole P2\P3 delineations and he pointed out that I may have been looking at it wrong. I had drank the kool-aid and wasn’t seeing the grey area.

The reality is the inter-dependencies of an application have to be managed when the application is grown at scale. For most traditional infrastructures this meant scaling each dependency as necessary like a multi-tiered architecture what we have called Platform 2. As we look past those traditional applications and onto the Cloud Native Apps with their micro-service builds we realize that the services come as containers themselves. I know I was disappointed too. It’s that the segmentation of monolith applications are just broken out to be 12 Factor consumable. This stinks but like a child finding out about mythological beings not being real I had to press on. So if I am just looking at containers am I understanding that they are isolated delivery modules better suited for mass distribution of an application. Maybe I was wrong about everything. As Tyler explained if we look at containers the distributed application dependencies aren’t always in other containers nor are they built as part of the container itself. Apparently containers can also be a hybrid app isolation, where large scale Oracle RAC could be the DB backend for a handful of containers deployed and managed via Chef, Puppet, Salt or Ansible.

It was like that weird commercial on TV where the people have their mine blown and purple smoke pours out. Because doesn’t the mixing of monolith and micro make strange bed-fellows or at the very least circus side show freaks. No it turns out that it actually makes a lot of sense. Next time I go to the bowling alley I am going to ask for bowling flip-flops and use a duck-pin puck instead of a ball. You can’t tell me how to do this Mr. Bowling Alley Operator, after all what are you going to do spray me with the shoe disinfectant?