A round-up of all sorts of container stacks, and some advice on what to do:
Therefore, the key lessons learned from this event (from developer’s perspective): Do not focus on developing code for the container under the hood. Care instead about the business logic. Implement your microservices in a vendor agnostic way.
Do not make the same fault as we all did with J2EE / Java EE where all vendors used the same standard specifications, but still offered many vendor-dependent features and “added value” in their specific “standard implementation”. Migration, i.e. deployment to another Java EE application server was a lot of efforts (re-development, testing, …); sometimes a complete re-write was easier and faster.
There’s a lot of fragmentation in container land now. This is what Linux must have felt like back in the late 90s.
Our advice at Pivotal, of course, is to focus on using Spring and other services towards the top of the stack for that layer of lock-in protection.
Pretty good piece from Harzog:
Management frameworks are dead because they have been unable to keep up with the pace of innovation in the enterprise computing industry. Management frameworks will be replaced by ecosystems of cooperating vendors that each reuse each others unique data through a common big data back end. Splunk is the first (but not the last) vendor to offer such a back end and to pursue such an ecosystem strategy.
From what I can tell, you could slot Boundary in as a hub there too.
Ecosystems over frameworks and platforms, in systems management
One of the first pieces I’ve written at the new analyst shop is now free, thrust out beyond the 451 paywall. I’m rebooting the application development coverage at 451 that’s been dormant for around 5 years. Don’t read that wrong, various aspects have been covering it here and there, but there hasn’t been an analyst focused on it. As such, I wanted to layout my “state of the union” of development.
Not too long ago, when Web applications dominated the software-development world, a developer’s primary decision was choosing a framework from the multitude of Web frameworks fine-tuned in the 2000s. Three forces have been changing that status quo in recent years: new devices and client delivery mediums, fragmentation of frameworks and platforms, and a renewed focus on design driven by catering to end users – not just IT buyers.
If I wanted to really summarize it, I’d say it was fragmented: more frameworks, delivery options, and end-clients than were available when I was a young programmer. It used to be just .Net and Java, desktop and web. Now there’s all sorts of languages, all sorts of ways to deliver software (through public cloud, traditional, as heavy GUIs, etc.), and all sorts of “screens” (as Adobe used to put it).
In addition to describing these “three forces,” I also wanted to point to how they might effect various folks in the tech ecosystem, like ISVs, service/cloud providers, and regular old companies inching into the whole “software is eating the world” jag.
Anyhow, tell me what you think. I’m hoping to evolve these ideas and explain-out the little nooks and crannies ongoing.
Why software development is different now
The latest Windows PC vs mobile platforms marketshare from @asymco/Gartner.
“We really should have one silicon interface for all of our devices. We should have one set of developer APIs on all of our devices,” said Terry Myerson, executive vice president of Microsoft’s Operating Systems Engineering Group, during the company’s meeting with financial analysts on Thursday.
Microsoft OS chief: One API to rule them all