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?

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.

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.