If you’ve already got the action figures, get the beer!
If you’ve already got the action figures, get the beer!
As a heavy RSS user, I care a lot about Feedly. So, when they announced that they’d gotten 50,000 paid subscribers, I threw together some quick math:
This isn’t a perfect comparision because the terms of subscriptions are different. The first 5,000 subscribers came from a Kickstarter selling a lifetime subscription for $99 (I was lucky enough to get in on that). The next batch – 45,000, I presume – are paying $45/year.
Still, there’s some cash. Hopefully it’s eough to keep it going. I actually just use Feedly for a backend as I do most of my reading in Newsify. What I’d really like is Flipboard to work with Feedly. But, you know, this isn’t the mid-2000s when things like that would happen.
My latest Pivotal blog post is up, it re-caps a presentation I did recently covering what “the market” is doing with continuous delivery.
There’s a lot of opportunity, the glass is half full. See the slides over in my previous post on this talk.
Also, check out the recording of the full talk (it has some bonus material on containers recent role in CD) from HeavyBit, embedded above.
Some good stuff from the latest from the $600m private cloud the CIA got from Amazon, including:
Meanwhile, Wolfe also acknowledged lingering industry criticism of its 2013 decision to award the $600 million cloud computing contract to AWS, essentially putting all the agency’s eggs in one basket. IBM unsuccessfully protested the cloud contract award to AWS. The CIA official defended the contract award this week, saying it provided AWS with nothing more than concrete pads and power to build the CIA cloud datacenters. AWS delivered all other cloud infrastructure and was up and running in less than 18 months, he added.
The scary thing would be if Amazon can build a $100m private cloud…a $10m one…then things get weird for vendors who are trying to achieve asymmetric competition with Amazon by hiding in private cloud land.
Also some fun anecdotes on resistance to change.
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.
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.
Why are frequent deployments important? If you can deploy hundreds of times per day, you can recover from mistakes almost instantly. If you can recover from mistakes almost instantly, you can take on more risk. If you can take on more risk, you can try wild experiments—the results might turn into your next competitive advantage.
There’s plenty to like in here from this 2013 talk, tips and such. Also, see this more recent interview, in text, for example:
[Y]ou have to start with a position that all organizations (it doesn’t matter what industry you’re in) are going to be disrupted by highly agile, highly automated competitors who leverage technology to be the disruptive force in the sector. And, businesses clearly have a choice as to whether they are going to be the ones doing the disruption or whether they are going to be the ones having to respond to the disruption. But in either case, it depends on your ability to adapt, change and to compete. We live in a world that is increasingly digital and where technology is the lever through which much of that computation takes place. My advice to IT folks is that you’ve got to be able to have that conversation in the voice of business leaders – you’ve got to be able to articulate that reality in a language that can be understood. This is not a technology conversation, it’s a business and a competitive strategy conversation.
Also, see the slides.
From a 2013 McKinsey survey on “going digitial.” The read is: you have to change to “culture” (business process and/or orginization) to take advantage of all that “software is eating the world stuff.”
Here’s their analysis:
Organizational issues can also hinder companies’ efforts to meet goals and see real impact from digital. As in 2012, executives most often say misaligned organizational structures are the biggest challenge their companies face in meeting digital goals. This is followed by insufficiently reworked business processes (to take advantage of the digital opportunities) and difficulty finding functional talent (such as data scientists or digital marketers). In contrast, a lack of infrastructure and absence of good data are less pressing than they were last year.
Its a real thing! Sadly: out of stock.