A few weeks back, we took a look at the curious case of the open source service mesh Istio and its on-its-face contradictory decision to abandon microservices and return to the monolith. This week, we find a headline from none other than Google cloud native adherent and evangelist Kelsey Hightower, who writes — as part of his series of “unpopular opinions” — that monoliths are the future.
Yes, you read that right.
Hightower lays out the problem clearly in the first sentence of the blog post: “Monoliths are the future because the problem people are trying to solve with microservices doesn’t really line up with reality.”
So what exactly is this problem that people are trying to solve with microservices in place of monoliths? Hightower lays out a hypothetical (that’s not so hypothetical) about a company lacking discipline that ends up with a disaster of a code base and, in response, decides to go with microservices as a solution — as a way to decouple different bits of disparate code from one another.
We need to do a better job of recognizing that the average IT organization does not have the same skillset as the engineering teams at Netflix.
— mike_pfeiffer (@mike_pfeiffer) January 27, 2020
The reality, says Hightower, is that “now you went from writing bad code to building bad infrastructure that you deploy the bad code on top of.”
What’s even worse, writes one HackerNews commenter, is that companies often end up breaking their monoliths into “microservices” only to end up with a distributed monolith, rather than microservices. So now, they enjoy increased complexity on the infrastructure end of things with a codebase that offers none of the actual advantages of microservices.
“Most people think a microservice architecture is a panacea because ‘look at how simple X is,’ but it’s not that simple. It’s now a distributed system, and very likely, it’s a the worst-of-the-worst a distributed monolith,” they write, outlining some basic points to help identify if this is where your new non-microservice architecture lands — the most obvious of which perhaps being “Service X does not work without Y or Z, and/or you have no strategy for how to deal with one of them going down.”
I wonder which part of the hype cycle this puts us on?
This Week in Programming
- How About A Side of AI With Your AI? When you’re dealing with the large image datasets needed to train object detection models, hand labeling can be a “daunting task” but IBM has released a Cloud Annotations tool to ease the process of AI data labeling, which uses AI to help label images…to train your AI. The new tool is accessible using the open source Cloud Annotations project, which will auto label images you upload using AI, and allows you to “store as much data as you need, access the data from anywhere and share across multiple collaborators in real-time.” Check it out.
Cloud Annotations now has auto labeling 🎉 It’s an early beta, but you can now upload a model to your project and let it do the labeling for you! pic.twitter.com/cEXJQVW2xl
— Nick Bourdakos (@bourdakos1) December 3, 2019
- Python Pandas Reaches 1.0: The Python pandas data analysis and manipulation library has finally achieved version 1.0 after more than a decade, and JaxEnter has an interview with Tom Augspurger, a member of the pandas development team, who says that “the 1.0 release does not mean a conclusion, or even slowing down, of pandas’ development.” The article looks at the release through the eyes of Augspurger, while DevClass also writes about the latest pandas version, offering a more straightforward detailing of the library’s newest features.
- GitHub Debuts Actions API in Beta: It’s been nearly a year and a half since GitHub first introduced Actions, its workflow tool that it later expanded into the CI/CD use case that everyone saw with its initial release. Now, the company has finally released a beta of an Actions API, which enables customers to manage GitHub Actions using a REST API, including the management of Secrets and Self-hosted runners. Now, before you go building on this new API, heed GitHub’s caveat that they “may change aspects of these APIs based on developer feedback […] but we will not provide any advance notice.”
Developers sitting in meetings and fixing CSS bugs all day:
“Funny how I get paid for this”
Developers working on open-source software that thousands of companies and developers depend on:
“Funny how I don’t get paid for this”
— David K. 🎹 (@DavidKPiano) January 27, 2020
- Getting Into Open Source on GitHub: One more bit from GitHub this week, as the company created a new feature to make it easier to start contributing to open source by helping you find good first issues, breaking it down into a few methods. First, you can browse by topic, by going to github.com/topics/<topic> — such as github.com/topics/machine-learning or by visiting github.com/topics to browse a list of topics. Next, if you have a project in mind, you can find beginner-friendly issues for that project by visiting github.com/<owner>/<repository>/contribute. And finally, if you’ve already contributed to some things but aren’t sure where to look next, you can go to github.com/explore to see your curated list, according to your past contributions, stars, etc. If you’re curious how GitHub made the feature, the company also offers a blog post on “the machine learning algorithms that made this feature a reality.”
- Go 1.15 Plays It Safe: With the release of Go 1.14 nearly upon us, the Go team has put out a blog post outlining proposals for Go 1.15, writing that, “per the process outlined in the Go 2, here we come! blog post, it is again the time in our development and release cycle to consider if and what language or library changes we might want to include for our next release, Go 1.15, scheduled for August of this year.” The team notes that error handling ran into some opposition earlier this year, with the try proposal, and that no good (superior and non-controversial) alternative has since been suggested so…they’re going to just let that one slide for now. Meanwhile, modules and generics are actively under development, while “some perennial favorites such as requests for enums and immutable types” lack sufficient development and urgency. Thus, the team writes that they have “concluded that it is better to hold off with major changes this time” and instead “concentrate on a couple of new vet checks and a minor adjustment to the language.” Go 1.15, therefore, tentatively comes with three minor proposals that the Go team says they hope to have “implemented at the beginning of the Go 1.15 release cycle (at or shortly after the Go 1.14 release) so that there is plenty of time to gather experience and provide feedback.” On an entirely separate but related note, Go team member Brad Fitz announced this week that he was leaving Google, writing that he would “still be around the Go community, but less, and differently.”
Open source is the foundation on which my career was built, and few have contributed more to my success than @bradfitz.
From the day memcached prevented my app’s imminent demise, to my first Golang contribution, Brad has set the bar for what it means to be a project maintainer.
— Kelsey Hightower (@kelseyhightower) January 27, 2020
— Abby Fuller (@abbyfuller) January 30, 2020
Feature image via Pixabay.