When you can pay the sprinkler repair guy by using your finger to sign an iPad, things are looking up. Maybe it means we’ll have lots of microservices wrapped around government services, who knows. Also, we cover the strategy of choosing boring technologies, MongoDB, and The EMC Federation.
With Brandon Whichard, Matt Ray, and Coté.
SPONSOR: Take our awesome, multi-cloud PaaS for a test-ride. Get two free months of Pivotal Web Services. Whether you want to deploy on-premises, in a dedicated public cloud, or just keep using our PaaS, Pivotal Cloud Foundry has everything you need for doing cloud-native applications. Go to cote.io/pivotal for the sign-up code!
Subscribe to this podcast: iTunes, RSS Feed
BONUS LINKS! Not covered in podcast
“For those not familiar with the concept, microservices is essentially a software architectural design pattern. The fundamental premise of microservices is that value can be unlocked through decomposing large, monolithic legacy applications into a set of small independent, composable services that each can be accessed via RESTful APIs.”
Five Things You Need To Know About Microservices | EMCInFocus
Nice talk from James Lewis on doing a microservices approach to solving a banking system problem.
Micro Services: Java, the Unix Way, 2013
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.
As Fowler and Lewis put it:
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.