When middle-management is screwing it all up – Pivotal Conversations

cover-art-051

Whether it’s “DevOps,” “digital transformation,” or even “cloud” and “agile,” middle-management is all too common an issue. They simply won’t budge and help out. This isn’t always the case for sure, but “the frozen middle” is a common problem.

With a big ol’ panel of people (including two folks from RedMonk), we talk about tactics for thawing the frozen middle.

The WTF on Cloud-Native from Kenny Bastani and James Governor – Pivotal Conversations

cover-art-052

Check out this talk on “cloud-native”:

We’ve got all your answers to “what exactly is ‘cloud-native’?” in this episode with special guests Pivotal’s Kenny Bastani and RedMonk’s James Governor. Kenny gives us a good overview of what cloud-native is, as Coté summarizes it: handling the configuration and automation for your applications along with all the supporting frameworks and platforms to do that. We then discuss the process (“culture”) angle, the origin of Spring Boot, the concept of “lock-in,” and if public cloud is needed or not. Bonus: serverless talk!

The crowded cloud native space

The wider Cloud Native ecosystem is, however, a very disparate and confused place. We anticipate a significant level of consolidation over the next twelve to eighteen months with some clear winners emerging. The emergence of several opinionated distributions of Kubernetes is hardly a surprise and this space will expand a little further before settling down.

Link

ARM deal analysis from RedMonk Rachel & 451

There’s some proper, and surprisingly concise deal analysis over there:

While growth has come from the IoT, ARM’s resurgence in recent years – and Intel’s opposite trajectory – have been the result of the London company’s dominance in mobile devices. (In 2015, “45% of the ARM-based chips went into mobile devices.”) The so-called Wintel monopoly carried both of those parties to valuations that ARM never approached, but as mobile steadily eroded PC spend ARM’s low power designs found success on both of the most successful mobile platforms. Both Apple’s iOS devices and Android’s array of hardware are either exclusively or nearly so ARM-based.

Check out the rest!

Meanwhile, from John Abbott at 451 Research:

  • ARM “generated less than $1.5bn in revenue last year and has only 3,300 employee”
  • “SoftBank will pay 20.9x trailing revenue for ARM. That’s the first time any company has cracked the 20x mark in a $1bn-plus chip acquisition.”
  • ARM “holds a 40% share in consumer goods, 30% in embedded intelligence, 15% in network infrastructure and 10% in automotive.”
  • “Revenue reached $1.49bn in 2015, up 15% from the previous year, with a net profit of $360.7m.”
  • Read more for his overall sentiment, which is basically: SoftBanks’ money and reach can fuel faster marketshare growth in these convert all the toasters to IoT grills times. checks out.

s/SOA/microservices/g

After a thrilling Tweeter-thread on SOA vs. microservices, I thought I’d just playing with some old text, here:

Decomposing an online store like Amazon.com, for example, into its fundamental piece parts yields a set of services – among them: a presentation service to deliver the HTML, a search service to find appropriate items, a shopping cart service and a credit card verification/payment service to check out and purchase items. While many speak of microservices purely in terms of RESTful services, it’s RedMonk’s view that RESTful services are not a prerequisite for delivering a microservices. RESTful services greatly ease the task of exposing services, but a microservices architecture should seek to exploit available services, resources and applications wherever possible. Indeed, many firms have run de facto microservicess using decades old mainframe applications without any assistance from Web technologies. An microservices should seek to exploit available services, resources and applications wherever possible.

You see, I replaced SOA with “microservices” and “Web services” with RESTful services.” Ha. Ha. ..and all that. That text is from a 2004 RedMonk piece on adding compliance to SOA. It was – and is! – good stuff.

Reads sort of OK. The funny part is, Amazon’s web page is still used today as a frog to disect to learn how microservices work.

The cludgy parts helps highlight how microservices are different, esp. how coarse-grained the Amazon examples above are. Don’t get me wrong, I’m not being “that guy” here. Instead, I’m just trying to run the diff and find the right parts to highlight vs. the “computers are awesome” stuff you’ll see around any IT idea.

As Fowler and Lewis put it:

This common manifestation of SOA has led some microservice advocates to reject the SOA label entirely, although others consider microservices to be one form of SOA, perhaps service orientation done right. Either way, the fact that SOA means such different things means it’s valuable to have a term that more crisply defines this architectural style.

Word up. Let’s try to make it work this time.