As noted in Matt Stines talk, along with advantages, such as scalability and tighter release cycles, microservices also have a number of downsides, including implicit interfaces, significant operational overhead due to redundancy, and operational complexity. As a result, managing microservices-based systems can become a nightmare, unless you use a PaaS\u2014e.g., Cloud Foundry.<\/p>\n

Cloud Foundry takes away a lot of the headache associated with running distributed systems. Here is how it helps to solve the most common issues:<\/p>\n

\n
• \n

  Implicit interfaces.<\/strong> In Cloud Foundry, microservices are deployed as applications and communicate through CF Router. When a service is published, it gets a unique URL in the Cloud Foundry domain. URLs and application routes are created automatically when an application is deployed. Router handles communication between applications in CF in the same way as if they were accessed from outside CF. However, the traffic does not leave the private network. In general, communication between apps in CF is not standardized\u2014there are many different options with various trade-offs.<\/p>\n<\/li>\n

• \n

  Significant operational overhead.<\/strong> With Cloud Foundry, application development is simplified considerably. It is just a part of application release life cycle. The PaaS handles development and staging, as well as production applications. There is no need to separate them into different IaaS deployments.<\/p>\n<\/li>\n

• \n

  Operational complexity.<\/strong> Cloud Foundry automates scaling and deployment of applications, as well as health monitoring and load balancing. You will not have to create additional scripts to automate monitoring and scaling in your IaaS. In a PaaS, Router serves as a load balancer, so you do not have to add it as a separate component (like when you are using an IaaS).<\/p>\n<\/li>\n

• \n

  Lack of DevOps skills.<\/strong> The high level of automation implemented in Cloud Foundry enables developers to concentrate on building and releasing applications. The development, testing, and production release processes are identical in terms of how you deploy. Additionally, the PaaS hides the complexity of the underlying IaaS solution.<\/p>\n<\/li>\n<\/ul>\n

  You can find more details on how Cloud Foundry helps to address the challenges brought by microservices in our guide<\/a>.<\/p>\n<\/span><\/div><\/div><\/div><\/div><\/div><\/div> <\/p>\n

   <\/p>\n

  <\/span>Want details? Watch the video!<\/span><\/h3>\n\n\n\n

  \n Table of contents<\/strong><\/p>\n \n Why microservices? (1:05)<\/li>\n How to modularize your data (2:33)<\/li>\n Getting business questions answered (16:41)<\/li>\n What is Lambda architecture? (17:32)<\/li>\n Managing microservices with a PaaS (23:17)<\/li>\n Sample microservices architecture (28:33)<\/li>\n Lambda architecture with Spring XD (31:22)<\/li>\n A sample app deployed to Pivotal Web Services (33:52)<\/li>\n A live demo of the sample app (35:15)<\/li>\n Gauging movie preferences (49:20)<\/li>\n The master dataset (56:40)<\/li>\n How to create reporting views (1:00:15)<\/li>\n Event sourcing and microservices (1:07:44)<\/li>\n Is the master dataset a single point of failure (1:09:06)<\/li>\n Why is it better to have raw data in your master dataset? (1:14:03)<\/li>\n Do you need to calculate batch view in the serving layer all the time? (1:16:23)<\/li>\n Is Spring XD the new Greenplum? (1:18:09)<\/li>\n<\/ol>\n<\/div>\n