Microservices and IBM Bluemix meetup presentation

Editor's Notes

• #10: Customers interviewed expect to realize a cost savings of 3 to 1 by automating much of the infrastructure and platform as a service (PaaS)
• #12: Don’t even think about microservices without DevOps Microservices cause an explosion of moving parts. It is not a good idea to attempt to implement microservices without serious deployment and monitoring automation. You should be able to push a button and get your app deployed. In fact, you should not even do anything. Committing code should get your app deployed through the commit hooks that trigger the delivery pipelines in at least development. You still need some manual checks and balances for deploying into production. See “Chapter 3, “Microservices and DevOps” on page 39 to learn more about why DevOps is critical to successful microservice deployments. 1.3.3 Don’t manage your own infrastructure Microservices often introduce multiple databases, message brokers, data caches, and similar services that all need to be maintained, clustered, and kept in top shape. It really helps if your first attempt at microservices is free from such concerns. A PaaS, such as IBM Bluemix or Cloud Foundry, enables you to be functional faster and with less headache than with an infrastructure as a service (IaaS), providing that your microservices are PaaS-friendly. 1.3.4 Don’t create too many microservices Each new microservice uses resources. Cumulative resource usage might outstrip the benefits of the architecture if you exceed the number of microservices that your DevOps organization, process, and tooling can handle. It is better to err on the side of larger services, and only split when they end up containing parts with conflicting demands for scaling, lifecycle, or data. Making them too small transfers complexity away from the microservices and into the service integration task. Don’t share microservices between systems.
• #19: Synchronous messaging is a simple and familiar mechanism, which is firewall-friendly. The disadvantage is that it does not support other patterns, such as a publish/subscribe model. The publish/subscribe messaging style is more flexible than point-to-point queuing, because it enables multiple receivers to subscribe to the flow of messages. This enables more microservices to be easily added on to the application. It also does not allow queuing of requests, which can act as a kind of shock absorber. Asynchronous messaging decouples the services from each other in time, enabling the sending thread to get on with work while the messaging system takes responsibility for the message, keeping it safely until it can be delivered to the destination. With synchronous applications, both the client and server must be simultaneously available, and the clients always need to know the host and port of the server, which is not always straightforward when services are auto-scaling in a cloud deployment. In such scenarios, one of the service discovery mechanisms described previously is required. Alternatively, an asynchronous mechanism uses a message broker, which decouples the message consumers and producers. The message broker buffers messages until the consumer is able to process them. A further benefit of messaging is that the back-end applications behind the queue can distribute workload among several clients. This type of worker offload scenario enables developers to build scalable, responsive applications. Implementing one or more instances of a back-end worker application enables the putting application to continue its work without the need to wait for the back-end application to complete. There are pros and cons to both approaches. Most applications use a combination of the two approaches to suit their needs.
• #23: Testing a complex system requires suites of unit and integration tests, and a testing framework that simulates failed or failing components, service degradation, stress testing, and the overall system’s behavior over the course of a typical day. Such test frameworks ensure system correctness and its overall resilience, and in turn can be used as a monitoring tool. Because of the focus on ensuring that the system behaves well when a component fails, it is not uncommon to test failure in the production environment in a microservices architecture. Automated tests that force a component to fail enable testing the ability of the system to recover, and testing the monitoring capabilities. Monitoring In addition to conventional monitoring systems, well-designed services can provide additional health check information using publish/subscribe over a messaging queue. In this way, information can be collected by the monitoring service, providing rich health and configuration indicators. These indicators in turn can be used to ensure that the services have enough capacity to serve current request volume, and compare current performance against expectations. Custom health checks can be registered to gather additional data. All collection information can then be aggregated, and displayed in the monitoring dashboard. DevOps The operations challenge of keeping microservices up and running means that you need high-quality DevOps skills embedded within your development team. The team needs to be operationally focused and production aware.
• #31: Infrastructure as a Service (and specifically IBM’s acquisition of SoftLayer) was the cloud’s initial answer to the need for faster deployments, faster environment setup, etc… by abstracting the infrastructure from the customer. IaaS Benefits Networking, Storage, Server, Vitualization managed by service provider. Most customizable cloud offering Solutions where` customizability of OS, Middleware, or Runtime needed IaaS Time Commitment Customer sets up and manages OS, Middleware, and Runtime - these still take at least a matter of days to setup and reach an initial deployment Maintenance/upgrades necessary as well
• #32: We’ve realized that, in a large number of use cases, our customers want to move even faster and don’t need to spend the time managing the platform (VM, OS, Middleware, Runtime). IBM’s answer: Bluemix (platform as a service). PaaS Benefits Setup your environment and deploy apps quicker than any other offering Service provider manages the Infrastructure AND the platform PaaS Time Commitment Minutes to initial deployment - developer can handle everything on his/her own Maintenance and upgrades of Platform and Infrastructure handled by service provider
• #34: Bluemix also allows flexibility when it comes to tooling - as, again, each developer has different preferences and needs. Tooling Options: IBM offers a web based integrated development environment (IDE) and associated git repository that allows quick deployments back to bluemix. Developers can also edit code on their local machines (with the editor of their choice - i.e. Sublime) and deploy back to Bluemix through the cloud foundry command line. Note to presenter: Other IDEs (like Eclipse, Cloud9) have direct integration with Cloud Foundry and can push code directly to bluemix, rather than a manual push by developer via command line. You may be asked about this.
• #38: Notes: So let’s start with a one page operation over view, then we’ll show you how it works. Works with scaling cloud group – group of instances Red – owns primary route Black – not active Step 1: Essentially, you have a cloud scaling group actively running App v1. The successor, or new version you want to put into place, is created but not receiving traffic. Step 2: The successor starts receiving production traffic. It starts with low traffic and is ramped up during testing phase. Testing is now begun and ends when it is determined that the new application is running properly – through performance metrics and operational conditions. Step 3: The original is disabled but available for instant roll-back. Step 4: The original group is scaled down and the successor continues as the new version. End: Now we’re finished and the new version is running – you’re users never knew you updated the software
• #42: Effortless - Visibility you need without taking any time or effort to learn or deploy something Innovate faster - Spend your valuable time innovating and delivering value to your users, not chasing bugs and performance issues Diagnose problems 90% faster - Quickly identify the root cause of application problems with code-level diagnostics Resolve problems with embedded analytics - Launch in-context search through logs and metric data to find the answers to your application problems Keep your app running - When your app is up, we can help you keep it up. Reduce your maintenance costs while improving availability