Breaking up the monolith with good, old fashioned, OO-think: Instead, Vanguard has begun a journey to break apart our monolithic legacy systems piece-by-piece by replacing them with microservices over time. With a microservices architecture, we remove the business logic and data logic from our applications and replace it with a set of re-usable modules of code that are built and deployed as independent entities. We then compliment this architecture by chunking out our user interfaces into modular purpose-built components.

From 451’s report on Google Next: Google believes that a hybrid architecture will persist in the coming years as enterprises continue to migrate workloads to various clouds. Its hybrid cloud architecture revolves around its virtual private cloud. Google VPC is an instantiation of GCP that can dedicate compute, storage and network resources to an enterprise. It is built upon Google's proprietary private global network designed for high reliability, low latency and hardened security.

If there’s one complaint that I hear consistently in my studies of IT in large organizations, it’s that government IT, as traditionally practiced, is fucked. Compared to the private sector, the amount of paperwork, the role of contractors, and the seeming separation between doing a good job and working software drives all sorts of angst and failure. Mark Schwartz’s book on figuring out “business value” in IT is turning out to be pretty amazing and refreshing, especially on the topic of government IT.

I started a new booklet project, the Cloud Native Cookbook. The premise is this: The premise of this book is to collect specific, tactical advice transitioning to a cloud-native organization. The reader is someone who "gets it" when it comes to agile, DevOps, cloud native, and All the Great Things. Their struggle is actually putting it all in place. Any given organization has all of it's own, unique advantages and disadvantages, so any "

In a report giving advice to mainframe folks looking to be more Agile, Gartner’s Dale Vecchio and Bill Swanton give some pretty good advice for anyone looking to change how they do software. Here’s some highlights from the report, entitled “Agile Development and Mainframe Legacy Systems - Something’s Got to Give” Chunking up changes: Application changes must be smaller. Automation across the life cycle is critical to being successful.

My colleague Richard has a nice post suggesting the new functions enterprise architects can play in a cloud-native organization. I like this one in particular, help make the change: Champion new team organization patterns. As an architect, you can bring developers and operations teams together. Recognize that functional silos slow down delivery. A DevOps-type approach really works. Architects are perfectly positioned to pioneer new team structures that increase velocity and customer attentiveness.

The San Francisco-headquartered business revealed it pulled in $187.7m last year, up 170 per cent from its $110.3m in revenue in 2015. Gross profits were just over $138m from $78m, and net losses decreased to a piddling $49.6m, down from $65.4m the year before. Another take from Barb Darrow, inc.: Mulesoft has raised $1.5 billion in venture funding from such backers as Lightspeed Venture Partners, Hummer Winblad, and New Enterprise Associates.

Some intersting history of how Facebook grew users. Of course, this the case study is for a free service, that focuses on a high volume of users. I.e.: not an enterprise sales business that charges $3m+ per user-cum-customers. Contextualizing aside, there’s some good product thinking: Better know what your product is good for: Knowing true core product value allows you to design the experiments necessary so that you can really isolate cause and effect.

A few weeks back my book review of two “the robots are taking over” came out over on The New Stack. Here’s some responses, and also some highlights from a McKinsey piece on automation. Don’t call it “automation” From John Allspaw: There is much more to this topic. Nick Carr’s book, The Glass Cage, has a different perspective. The ramifications of new technology (don’t call it automation) are notoriously difficult to predict, and what we think are forgone conclusions (unemployment of truck drivers even though the tech for self-driving cars needs to see much more diversity of conditions before it can get to the 99%+ accuracy) are not.

A nice discussion that highlights the complexity id trade policy and, thus, rhe high risks of fucking it up. I like this critique of trade criticism: What makes Navarro’s critique challenging is that it’s not wholly wrong, at least from the American worker perspective, yet it’s not particularly actionable. So often, that last part is overlooked: you have to actually be able to on something, despite the past. Until we have time machines, finding flaws and suggesting how we should have fixed them is little use on its own.