Presentation: No Microservice Is an Island

At Capital One, I was working on the first layer of services that our mobile app and website hit. Any new mobile or web request would first reach the service owned by my team.  This service implemented security and customisation logic and then made a server request to the broader Capital one ecosystem. Capital One has a lot of microservices.
QCon: And what do you work on now at Square?

At Square, I am working specifically on Capital’s underwriting service. If a merchant on Square wants a loan, this is the service which decides the loan eligibility of the merchant and manages the entire flow till loan approval.

There were a lot of people at Capital One who worked on Java, but I was working on Node there. At Square I am working on a ruby on rails monolith and we are working towards a microservices based architecture.

It is a very broad talk for people who may not necessarily have worked much on microservices. My team at Capital One was the first team to implement microservices. We addressed a lot of pain points initially and there was not much guidance then. We learned a lot through this experience. We learned about infrastructure needs, operational changes and monitoring required. The talk gives a holistic view of infrastructure needs and then dives into specific changes required for operation, security, resiliency and scalability. The audience would take-away something like a checklist, that they could use when implementing microservices.

It is intended mainly for people who have already started the journey towards implementing microservices. They may not understand all the intricacies at the moment but the talks would prepare them on what to expect in the future, when the number of microservices grows and they may run into problems. For example, at Capital One, there were times when it took days to resolve issues because we did not know who was the responsible team for a particular service.

The first example I can think of is that people don’t realise they are going to be scaling their systems. One of the benefits of microservices is that you can scale your services up or down based on the load on different parts of the system. So when building their initial deployment tooling, people need to realise that it may be reused in the future when they scale. Otherwise, they may end up maintaining two separate ways of deploying servers, one which is manual and another that is easy to scale.

I think the most important trend is working towards automation. Automation is widely applicable to so many different parts of the industry from computerisation projects to building automated cars. Irrespective of the application,  you need to identify the steps required for moving from a manual to an automated process where you might not need a human anymore to perform some of the actions.