When NOT to Do Microservices – InApps is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn When NOT to Do Microservices – InApps in today’s post !
Read more about When NOT to Do Microservices – InApps at Wikipedia
You can find content about When NOT to Do Microservices – InApps from the Wikipedia website
Microservices, microservices, microservices, microservices. By now, you’ve perhaps heard the word so much, you can’t help but return to the chant of “developers” by a sweaty Steve Ballmer on stage a decade ago.
Maybe your company has already made the switch, leaving behind its legacy monolith for the promised land of a distributed architecture, or maybe it’s just pondering the move. After all, everything’s better as a microservice, right?
This week, we hear the tale of one such software project that has gone down the path of microservices, only to decide that monolith was indeed the way to go, and it comes to us from a project you might otherwise think would do nothing other than be 100% all in on distributed architecture — the open source service mesh Istio.
The tale comes to us from Christian Posta, a field chef technology officer with Solo.io, who offers up Istio as an example of when not to do microservices, writing that “a microservices approach may be appropriate when the culmination of an application’s architecture has become a bottleneck (as a result of the various people/process/tech factors) for making changes and “going faster,” but it’s not the only approach.
In the case of Istio, you might imagine that a tool that is meant to “help solve difficult application-networking challenges introduced by a microservices/cloud architecture,” writes Posta, would be best served by a microservices architecture itself. Instead, Istio plans to revert to a more monolithic approach with Istio 1.5, expected out next month, for a simple reason, which Posta cites from some design docs: “The complexity of the microservices approach proved to not deliver the value or goals it intended. On the contrary, it worked against those goals.”
This article is spot on about microservice vs monolith trade-offs. As an Istio operator in our company, I’m very glad that istio is moving to a monolithic service. It is always easier to manage a “single binary”. BTW This is a design philosophy of Hashicorp products. https://t.co/wyI7Wv3c1C
— Pierre Besson (@pibesson) January 8, 2020
Posta offers a diagram that shows the complexity of the current implementation, and it has some semblance of a bowl of spaghetti. Skipping the nitty-gritty details of Istio itself, one bit in the middle of his post really captures the issue at hand here:
The #1 tradeoff when going to a microservices architecture is complexity. When you go from one thing (monolith) to a bunch of little things communicating with each other (to optimize for a particular concern), you significantly increase complexity both in the architecture as well as the infrastructure necessary to run things.
This may be a necessary tradeoff insofar you realize the benefits. If not, it’s best you evaluate your assumptions and correct course. That’s what’s happening with Istio right now.
The resultant diagram instead looks like the spaghetti while it’s still in the box — all neat and orderly and simple. Now, of course, this might be the tale of microservices in general, but the point is that all that complexity is only worthwhile in the end if it delivers the desired results. Whether it’s because of scaling concerns, the desire to use different languages for different purposes, domain groupings, or security concerns, there are valid reasons for microservices, but simply avoiding the feared term “monolith” is just not one of them.
For Istio, the move back to the monolith now offers its users some benefits that they did not enjoy while enduring the utopia of a microservice architecture, writes Posta, including a simple installation with a single deployable service, reduced configuration complexity, easier debugging, and an increased efficiency.
This Week in Programming
- Visual Studio Code’s 2020 Python Release: To start us off on the news end of things this week, all you Visual Studio Code Python developers have a new Visual Studio Code January 2020 release to install. The latest Python extension offers performance improvements in the Jupyter Notebook editor, kernel selection in Jupyter Notebooks, auto-activation of environments in the terminal on load, and fixes to rebuilding ctags on save and on start. Now, we know how much y’all like Python, and we hate to be the ones to break it to you, but…
- …C Is Now The Most Popular: Or at least, so sayeth the TIOBE Index, which is a ranking of top programming languages according to “the number of skilled engineers world-wide, courses and third-party vendors” and, well, searches on Google, Bing, what have you. While Python had taken the top spot for 2018, and, as they write in the blog post, “everybody thought that Python would become TIOBE’s programming language of the year for the second consecutive time,” C beat it out. Why? It gives credit for C’s popularity to the Internet of Things, where C is both universally available and fast. TIOBE also points to gains by Swift and Ruby as a standout, while Rust, Kotlin, Julia and TypeScript did not fare as well as expected. But hey, it’s all just a horse race, so code in what works, right?
— 404 Developer (@26th_edmund) January 6, 2020
- Ruby Releases 2.7 With Improved Garbage Collection: Speaking of Ruby, the 25-year-old language has just released Ruby 2.7 and InfoWorld brings us the details on the latest production release, which it says notably improves garbage collection and pattern matching. According to the release notes for Ruby 2.7, the features of note include pattern matching, improvement of the read-eval-print-loop (REPL), the introduction of compaction garbage collection, and the separation of positional and keyword arguments. Take a gander at either for the detailed explanations.
- Go Marches On with Go 1.14: Go, meanwhile, continues its march forward with Go 1.14, which InfoWorld again details, noting that this latest version focuses on runtime and compiler improvements, as well as to Windows and WebAssembly support. The release isn’t out quite yet, but rather expected for mid-February, and the release notes point to this version as “the last Go release to support 32-bit binaries on macOS.”
An underrated way to learn and stay current:
Read the docs.
I’ve worked in React since it was open sourced and often re-read the docs.
– I find new tips they’ve added
– I’m reminded of things I’ve forgotten
– I see new examples that resonate
Simple. Free. Current.
— Cory House (@housecor) January 4, 2020
If you are contemplating joining a coding bootcamp in 2020 then let me give you a list of the top scams they use to steal your money (yes, even with an ISA, the #1 scam):
— Zed A. Shaw, Writer (@lzsthw) January 1, 2020
Feature image: Post Malone, from Tore Sætre, via Wikipedia, CC BY-SA 4.0.
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.