Yes, microservices are just a rebranding of a SOA subset. 
<a href="http:&#x2F;&#x2F;martinfowler.com&#x2F;articles&#x2F;microservices.html#MicroservicesAndSoa" rel="nofollow">http:&#x2F;&#x2F;martinfowler.com&#x2F;articles&#x2F;microservices.html#Microser...</a> But I think this direction is inevitable, and we&#x27;ll soon see freemium microservices.<p>Amazon&#x27;s &quot;Lambda&quot; page (esp scroll down to the &quot;benefits&quot; 
<a href="https:&#x2F;&#x2F;aws.amazon.com&#x2F;lambda&#x2F;" rel="nofollow">https:&#x2F;&#x2F;aws.amazon.com&#x2F;lambda&#x2F;</a>
) shows it&#x27;s more like offloading some tasks (like worker threads in the cloud).<p>I had a play with the second (linked) app, SquirrelBin  <a href="http:&#x2F;&#x2F;squirrelbin.com&#x2F;" rel="nofollow">http:&#x2F;&#x2F;squirrelbin.com&#x2F;</a> which can edit and run javascript snippets. The latency is awful, 2-3 seconds for me (I&#x27;m in Australia, but that should only add 200ms roundtrip or so). They seem to spin up (reuse?) an entire instance for <i>each request</i> - it&#x27;s incredible that it&#x27;s as fast as it is.<p>But the problem is the architecture of this specific app: the delay would be fine if you could edit-run-loop code locally, without the cloud. But they wanted to demonstrate quick development (for them) by just making a CRUD app, using AWS Lambda existing http endpoints for PUT, POST, GET, DEL.  So after editing you have to save, load and run - and each one interacts with the cloud. BTW the article about SquirrelBin 
 <a href="https:&#x2F;&#x2F;aws.amazon.com&#x2F;blogs&#x2F;compute&#x2F;the-squirrelbin-architecture-a-serverless-microservice-using-aws-lambda&#x2F;" rel="nofollow">https:&#x2F;&#x2F;aws.amazon.com&#x2F;blogs&#x2F;compute&#x2F;the-squirrelbin-archite...</a>