Microservices 101: The good, the bad and the ugly (ZDNet)

[Posted July 10, 2015 by jake]

ZDNet has an interview about "microservices" with Red Hat VP of engineering for middleware, Dr. Mark Little. Microservices are a relatively recent software architecture that relies on small, easily replaced components and is an alternative to the well-established service-oriented architecture (SOA)—but it is not a panacea: "'Just because you adopt microservices doesn't suddenly mean your badly architected ball of mud is suddenly really well architected and no longer a ball of mud. It could just be lots of distributed balls of mud,' Little said. 'That worries me a bit. I've been around service-oriented architecture for a long time and know the plus points and the negative points. I like microservices because it allows us to focus on the positive points but it does worry me that people see it as the answer to a lot of problems that it's never going to be the answer for.'"

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 12, 2015 3:36 UTC (Sun) by b7j0c (guest, #27559) [Link] (21 responses)

RedHat's model is just more code and ops for a world that is increasingly seeing both internal code and ops as liabilities, hence the sharp rise in hosted APIs that scale.

For the same cost of implementing RedHat's microservice recommendations on your own hardware, you could run APIs on any of the major cloud API providers for years...with vastly reduced time to market, no concerns about scaling, better security, and the opportunity to finally spin down your horrible internal kinda-NOC.

In a few years most people delivering solutions on AWS, Azure or GCE won't even know what an "instance" is, those details are already being obscured, see AWS' recent API hosting service. I'm not even a huge fan of Amazon as a company, but there is simply no disputing that being able to trigger Lambda events on APIs that are hosted at arbitrary global scale by the new API service is a game-changer.

RedHat is going to have to take some very big risks to stay relevant in the new world of instant-on, arbitrarily scalable services. Software isn't enough.

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 12, 2015 11:56 UTC (Sun) by Lennie (subscriber, #49641) [Link] (20 responses)

We've had this discussions in different versions before, but you don't seem to worry about loss of control in any form.

Maybe some XKCD helps ;-)

https://xkcd.com/743/

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 12, 2015 14:35 UTC (Sun) by ibukanov (subscriber, #3942) [Link] (2 responses)

On the other hand as "Markets can remain irrational longer than you can remain solvent", retaining control can cause bankruptcy before the cloud fails. It is interesting to watch this indeed.

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 12, 2015 15:09 UTC (Sun) by Lennie (subscriber, #49641) [Link] (1 responses)

All I've been saying on lwn.net is add some flexibility to what you are deploying.

Let's say you want to have an automated deployment of something on VMs on AWS. Use the AWS API to automatically create and start VMs, instead of using the auto-scaling groups and tying yourself to the cloud provider.

Now if you only depend on an API to create VMs if you want to use Digital Ocean instead of AWS you pretty easily do that.

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 12, 2015 17:51 UTC (Sun) by ibukanov (subscriber, #3942) [Link]

Yes, the key is to embrace the cloud to take in short term advantage of the skills that a market leader possess but make sure that long-term harm from that leader diapering (court order, state-sponsored targeted hacking etc.) with all the data and services is limited, like having a working backup and deployments scripts for a new provider ready.

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 13, 2015 17:22 UTC (Mon) by b7j0c (guest, #27559) [Link] (16 responses)

> but you don't seem to worry about loss of control in any form

Once you have to maintain a rack of servers in a building, your freedom has been lost anyway. Why don't people realize their bespoke architectures are as bad a "lock-in" as the cloud? Look at it this way...your bespoke architecture is a one-off, non-scalable, insecure cloud designed for one user.

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 13, 2015 17:32 UTC (Mon) by dlang (guest, #313) [Link] (5 responses)

> Look at it this way...your bespoke architecture is a one-off, non-scalable, insecure cloud designed for one user.

only if you build it that way.

Why don't you stop assuming that people are incompetent to run their own systems and insulting them at every chance you get.

Just because you have decided that the Cloud is the way to go for you doesn't mean that it's right for everyone.

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 13, 2015 17:52 UTC (Mon) by b7j0c (guest, #27559) [Link] (1 responses)

> Why don't you stop assuming that people are incompetent to run their own systems and insulting them at every chance you get.

I neither insulted any individual directly nor did I dictate development practices to you. I commented on an LWN story, nothing more.

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 14, 2015 19:02 UTC (Tue) by flussence (guest, #85566) [Link]

> I neither insulted any individual directly nor did I dictate development practices to you.

Neither of which are the point of the criticism you received; it apparently flew right over your head.

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 16, 2015 16:31 UTC (Thu) by jwarnica (subscriber, #27492) [Link] (2 responses)

At some point, you are buying cycles, memory, storage. Buy them from HP, IBM, Dell, EMC, or buy from Amazon, Azure, Bobs Cloud.

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 16, 2015 23:51 UTC (Thu) by dlang (guest, #313) [Link] (1 responses)

and as always, every time you add a middleman you have to add in their profit margin as well (but hopefully benefit from any economics of scale they have)

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 17, 2015 11:43 UTC (Fri) by Lennie (subscriber, #49641) [Link]

Actually

"HP, IBM, Dell, EMC, or buy from Amazon, Azure, "

Probably they are all middlemen.

It has been shown Google, Facebook and even Microsoft design some of their own hardware and place orders in China directly. There is no HP, IBM, Dell, EMC involved in that process.

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 13, 2015 19:52 UTC (Mon) by Lennie (subscriber, #49641) [Link] (9 responses)

The point I was trying to make is to create software that doesn't depend on the environment.

Instead of you seem to be saying: you should move stuff to the cloud.

I'm saying: make sure where ever you deploy it that you can easily pick it up to run it somewhere else. Don't put all your eggs in one basket.

Obviously not everybody has figured this out yet, there are still a lot of companies that depend on Oracle. What an awesome supplier that is ;-)

http://thestack.com/oracle-breach-notice-cloud-services-1...

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 13, 2015 20:36 UTC (Mon) by b7j0c (guest, #27559) [Link] (8 responses)

> The point I was trying to make is to create software that doesn't depend on the environment.

But you always do. You either depend on Postgres or Perl or C++ or Go or your ops team or some hardware etc etc or all of the above. None of it is "free", there is always the cost of your time, proprietary glue code, people in ops to pay, a colocation bill, some "bus factors"...yet no one really balks at creating and maintaining all of this because it is the accepted way we do things.

Most people have single-points-of-failure in their physical assets like headquarters, people etc, but no one thinks it is realistic to try to make all of that redundant either, its just a risk of being in business.

You should treat your infrastructure as another risk of cost and benefit. My point isn't that the cloud is risk-free...simply that for most time-sensitive initiatives, the benefits drastically outweigh the costs.

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 13, 2015 22:45 UTC (Mon) by dlang (guest, #313) [Link] (6 responses)

> But you always do. You either depend on Postgres or Perl or C++ or Go or your ops team or some hardware etc etc or all of the above. None of it is "free", there is always the cost of your time, proprietary glue code, people in ops to pay, a colocation bill, some "bus factors"...yet no one really balks at creating and maintaining all of this because it is the accepted way we do things.

and almost none of that goes away if you move to the cloud

> You should treat your infrastructure as another risk of cost and benefit. My point isn't that the cloud is risk-free...simply that for most time-sensitive initiatives, the benefits drastically outweigh the costs

the thing is that there are far fewer "time-sensitive initiatives," than the cloud advocates would like to think.

It also takes a substantial amount of effort to properly operate in the cloud, your ops and dev teams need to work differently than they can with your own infrastructure. If you are starting from scratch you can argue that it's about equal effort to get up to speed on either option, but if you have a large knowledge pool for internal systems, switching to a cloud system has a learning curve that can outweigh the 'speed' advantage that cloud advocates claim.

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 14, 2015 3:09 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

> and almost none of that goes away if you move to the cloud
That depends. For example, my friends used:

- Amazon RDS for the database
- Amazon Elastic Beanstalk to host their application with automatic load balancing and scaling.
- Google for mail/calendar/documents
- Github for code.

And they don't need a full-time sysadmin to support this, it literally was set up (by me) in about 1 hour of clicking through web setup dialogs.

> the thing is that there are far fewer "time-sensitive initiatives," than the cloud advocates would like to think.
Sure. But procuring and setting up real physical hardware usually takes much longer than clicking a couple of buttons in a console.

For now, cloud can surely be more expensive than private clouds but mostly for niche purposes. And if you need something _fast_ without investing in full-time sysadmins to support it, real hardware loses.

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 14, 2015 4:57 UTC (Tue) by dlang (guest, #313) [Link] (4 responses)

"we don't need no stinkin sysadmins: is the worst way to approach to cloud or devops

talking about how setting something up is only a few clicks and a little time but ignoring the long term planning and maintenance is a classic mistake (and why devops is a curseword in some circles)

it works for experimentation (much of the time), but if you actually want to run a reliable service over time it needs the planning and maintenance that a sysadmin provides. If you don't have anyone else, you become the sysadmin.

the work doesn't go away just because you move things, you trade caring for physical servers for adapting to a vendor's API and the changes that are going to happen on their schedule.

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 14, 2015 6:56 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

> talking about how setting something up is only a few clicks and a little time but ignoring the long term planning and maintenance is a classic mistake (and why devops is a curseword in some circles)
Why do you think use of Cloud ignores long-term planning? This company eventually outgrew Elastic Beanstalk and set up custom infrastructure (also on top of the AWS).

And since Elastic Beanstalk is used by many companies and is extensively documented, migration was extremely easy.

> it works for experimentation (much of the time), but if you actually want to run a reliable service over time it needs the planning and maintenance that a sysadmin provides. If you don't have anyone else, you become the sysadmin.
Why do you think Elastic Beanstalk (or Azure App Service) are not reliable? They are managed by teams of qualified professionals, with multiple 24-hour on-call support engineers.

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 14, 2015 7:34 UTC (Tue) by Lennie (subscriber, #49641) [Link] (2 responses)

We are talking about a completely different scale here too I think.

Your friends sounds like a pretty small bunch of people.

A large company with 100s, maybe even 1000s of projects being worked on at a time might come to a completely different conclusion.

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 14, 2015 17:29 UTC (Tue) by b7j0c (guest, #27559) [Link] (1 responses)

The bigger the org, the better they can exploit provisioned resources. This is why AWS was initially adopted by many large orgs (DropBox, Netflix, etc) and has most of its use dominated by them.

A large organization may have a daily flux in requirements of thousands of instances, dozens of databases, dozens of queues. Plus of course the beta/test environments, which doubles costs.

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 14, 2015 19:14 UTC (Tue) by raven667 (subscriber, #5198) [Link]

It's true that many large orgs use AWS and rent server time but the big value proposition is for small firms who can get a higher level of service by renting that they could never achieve by owning. A big group like Netflix or Dropbox have the resources to build their own infrastructure at a similar quality level as AWS like Facebook does, they just choose not to. There is probably a case to be made that developing infrastructure in-house distracts focus from their developing their primary business offering but financially the profit they pay Amazon at large scale to rent by the minute could probably pay for the headcount and capitol to manage the infrastructure in-house.

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 13, 2015 23:11 UTC (Mon) by Lennie (subscriber, #49641) [Link]

Ahh, we are getting closer to the middle ground. :-)

I wouldn't mind using a PaaS provider for building a quick prototype.

But I would prefer using IaaS instead of PaaS for something more substantial to prevent vendor lock-in.

This is why I think containers and Docker are a very useful compromise and approach to abstract your code from the underlying infrastructure.

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 12, 2015 11:53 UTC (Sun) by torquay (guest, #92428) [Link] (13 responses)

"... doesn't suddenly mean your badly architected ball of mud is suddenly really well architected and no longer a ball of mud."

Pot, kettle, black. RHEL is a mud ball in the first instance, with no clear separation between apps and the OS (among other crimes).

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 12, 2015 13:11 UTC (Sun) by pizza (subscriber, #46) [Link] (1 responses)

The problem with all of this "Service" and "abstracting" handwaving is that folks forget that at some point the turtles have to stand on something in order to actually interface to the real world.

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 13, 2015 14:54 UTC (Mon) by SEJeff (guest, #51588) [Link]

You're not fooling me, it's turtles all the way down!

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 12, 2015 14:25 UTC (Sun) by HelloWorld (guest, #56129) [Link] (1 responses)

> no clear separation between apps and the OS
Yeah, just like pretty much every other Linux distro. Except that Red Hat actually pays somebody to work on fixing this, i. e. the whole systemd/Gnome application containers thing.

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 13, 2015 5:55 UTC (Mon) by salimma (subscriber, #34460) [Link]

Not to mention the interesting work on "rings" being done as part of the Fedora Server working group, which should trickle down into the next version of RHEL

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 13, 2015 11:45 UTC (Mon) by nim-nim (subscriber, #34454) [Link]

Actually Red Hat is thriving precisely because RHEL is sane and sturdy enough to resist the garbage app people sell to enterprises.

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 13, 2015 14:55 UTC (Mon) by SEJeff (guest, #51588) [Link] (7 responses)

Have you even seen RHEL Atomic? For Atomic, your comment simply could not be further from the truth.

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 13, 2015 16:38 UTC (Mon) by drag (guest, #31333) [Link]

I've been using it and so far it's pretty awesome.

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 14, 2015 7:24 UTC (Tue) by torquay (guest, #92428) [Link] (5 responses)

erm? Atomic is for running Docker containers. I'm referring to user-facing stuff like evince, firefox, libreoffice, gimp, etc. They spew their files all over the file system, mixing in with OS level components. On top of that, a security hole in firefox has the potential to expose all of the user's data.

Or is there already a containerized version of firefox?

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 14, 2015 14:43 UTC (Tue) by drag (guest, #31333) [Link] (1 responses)

> Or is there already a containerized version of firefox?

There is, but it's not going to be easily usable in a manner that is suitable for a workstation or desktop. People are working on sandboxing/containerizing desktop applications, but desktop requirements are always significantly higher then individual servers.

> erm? Atomic is for running Docker containers. I'm referring to user-facing stuff like evince, firefox, libreoffice, gimp, etc.

What on earth does it have to do with 'Microservices'? Regardless, the atomic hosts are very stripped down. You are not going to have to worry about firefox vulnerabilities.

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 14, 2015 15:06 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

FWIW

https://lists.fedoraproject.org/pipermail/desktop/2015-Ju...

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 14, 2015 15:21 UTC (Tue) by raven667 (subscriber, #5198) [Link]

> I'm referring to user-facing stuff like evince, firefox, libreoffice, gimp, etc. They spew their files all over the file system, mixing in with OS level components. On top of that, a security hole in firefox has the potential to expose all of the user's data.

This problem has had a lot more work put into solving it on the mobile platforms like iOS and Android, to prevent end-users from destroying their phones when installing third-party software, by heavily sandboxing the apps and providing much more restricted APIs for them to communicate with one another and with the OS. This style of user-facing software deployment is no longer experimental but is now a proven standard, unfortunately the number of man-hours it will take to shoe-horn existing software into the sandboxed app-store model means that we are years away from having this be the default on traditional Linux distros.

ChromeOS is probably the leading Linux distro here, one of the few that sells significant amounts of hardware to the non-IT-employee market.

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 15, 2015 4:07 UTC (Wed) by SEJeff (guest, #51588) [Link] (1 responses)

https://www.youtube.com/watch?v=1qlLUf7KtAw a talk on containerized desktop applications

https://blog.jessfraz.com/post/docker-containers-on-the-d...

Microservices 101: The good, the bad and the ugly (ZDNet)

Posted Jul 15, 2015 10:03 UTC (Wed) by torquay (guest, #92428) [Link]

Looks like each desktop app was containerized by a bunch of dedicated hand-tuned hacks.

However, it is very cool as an effective technology demonstrator... even PulseAudio was containerized!