Some highlights from a recent survey on container usage among 338 respondents to a Anchore/DevOps.com survey:
Containers in production:
…approximately one third of the participants are running containers in production, with development coming in slightly higher.
Looking at the top five host operating systems across user roles we see Ubuntu having a particular strong lead among developers and architects.
Mesos, architect-types like it:
Interestingly Mesos still features strongly with architects. Among developer communities we very rarely hear Mesos mentioned anymore. On the other hand we frequently encounter architects have invested in Mesos from the perspective of their big data environments and are looking at a common approach for their container strategy. That said, this entire market is extremely fluid at the moment.
Jenkins leads CI:
…the combination of Jenkins and CloudBees (commercial Jenkins) approaching 50%.
Bluntly put [security] presents a barrier to adoption, and an opportunity for conservative organisations to hold off on adopting new technologies.
Our population breaks out with over 60% working in companies of greater than 100 people [and ~30% working in companies of greater than 5,000 people]…. With any data set of this nature, it is important to state that survey results strictly reflect the members of the DevOps.com community.
- As you’ll recall, 451 estimates that the container market will be $2.7bn in 2020.
- A 451 Research 1Q16 survey puts production use of containers at ~14%. It’s likely risen sense then, of course: maybe to around 18 to 20%?
- A 3Q2015 survey put “container orchestration” use at just ~9%. Presumably this is dev/test and production, all uses. And, again, you’d assume that it’s risen since then. The question would be: are people using containers in production without orchestration? That seems slightly crazy except for the simplest workloads, eh?
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.
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!
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.
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.