Nice talk from James Lewis on doing a microservices approach to solving a banking system problem.
“But microservices want to bring you into tomorrow,” says Winterberg. “Microservices add a bit to the category concept, defining a service over all application layers, including the UI. So people already doing SOA may gain a kind of new freedom by adopting microservice ideas.” That freedom includes technology independence and an alternative to aging technologies, because individual services within an application can be gradually swapped out for those based on more-modern technologies, without having to replace the entire application. “Classic SOA is more platform driven, so microservices offer more choices in all dimensions,” says Winterberg.
The picture that emerges is not of microservices as an alternative to SOA, but rather as a way to restore flexibility that may have been lost in SOAs that became too rigid and monolithic.
Microservices is a modern take on software architecture, in which complex applications are composed of small, independent processes communicating with each other using APIs. These services are small, highly decoupled and focus on doing a small task. The rise of Docker, the proliferation of third party developer tools and the increasing reliance on the cloud all play into the growth of microservices.
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.
Early on, vendors who wanted to compete with AWS would speak to the idea of an “enterprise cloud.” All the US Federal activity that AWS had been up to – including that $600m private cloud for the CIA – seems to nullify most of that.
I think what will be more important is targeting the type of application supported: old school, three tier app that are statefull everywhere, or cloud native, microservices apps that are stateless (shoving statefullness of to caches and databases).
Distributed transaction is, I would say, it’s an anti-pattern, and it is very hard to code in if there are like writes in transactions that need to happen in different places, in different databases, it makes it very difficult to make sure everything works really well.
Finishing projects is hard, starting them is easy. That said, the moment of starting a project is critical, and assembling the team is incredibly impotent. We discuss that staff boot-strapping and the types of people who are good and not good for starting projects. We also discuss microservices and how this emerging style of architecture can help the product and business side out.
- Projects don’t start often, most of them are “old” ones
- Bill’s “special projects” LinkedIn status.
- Keeping a list of people you’d want on your team
- Recruiting the people – the painful part is the extraction process, moving them from their existing work to the new work
- Finishing stuff is hard, starting is easy
- While the project may come and go, the people have probably worked together several times before
- Check out the Apple take, according to “Mr Ive.”
- We try to summarize the thinking behind microservices. Other than pointing to existing things – the web – we think of it as “SOA that works this time.”
- Based on this great write-up from James Lewis and Martin Fowler.
- Coté’s mindmap on the topic.
- They seemed to loose track of “speed” in SOA, where-as microservices is very focused on shipping, not perfectly modeling
- We discuss the “business benefit” of mashups, composite applications, and thus, microservices architecting: enabling experimenting on the side, like all the Evernote apps… pace layering at the architectural layer means you can pace layer at the product management level.