Old dog, new tricks

Refactoring an ASP.NET/IIS monolith to composable polyglot Docker-hosted mini-services

JAX Editorial Team
Docker
Mark Rendle at JAX DevOps 2016

In this talk, Mark Rendle, founder and CEO of RendleLabs will share the challenges he encountered when refactoring an ASP.NET/IIS monolith to composable polyglot Docker-hosted mini-services, the things he learned along the way and the benefits he gained.

CloudLens was a traditional ASP.NET MVC 5 and WebAPI 2 application, run in every public Azure data centre in the world, hosted on IIS in Microsoft Azure Web Sites. Then Microsoft announced the cross-platform, open-source .NET Core and ASP.NET 5, soMark Rendle, founder and CEO of RendleLabs spent 2015 porting the application code to the new system, breaking it down into mini- and micro-services, rewriting bits in different languages, and getting it running in Docker containers on Linux VMs with an open-source orchestration platform.

In this talk, he will share his experiences, the challenges he encountered, the things he learned along the way and the benefits he gained.

JAX DevOps 2016: Refactoring an ASP.NET/IIS monolith to composable polyglot Docker-hosted mini-services – Mark Rendle from JAX TV on Vimeo.

Mark Rendle is the founder and CEO of RendleLabs.

 

Don’t miss our interview with Mark Rendle:

JAXenter: How was the change from traditional ASP.NET MVC 5 and WebAPI 2 to open-source .NET Core and ASP.NET 5? Did it match your expectations?

Mark Rendle: It was – and still is – challenging, but in a very good way. The new ASP.NET Core MVC framework is like a combination of the best bits of MVC and Web API, and there’s no break between the two now, so you use the same setup, configuration, middleware and other components for your page-rendering controllers and your API controllers. I’ve been able to import most of the C# and Razor code from the old source code and get it working without too much effort.

The nicest thing has been being able to go and look at the ASP.NET Core source code on GitHub, so I can check how to do things, or look at how the internal framework tests are written, for example. I’ve also done most of the actual development work on Linux, using open source editors and the OmniSharp plug-in, which has worked pretty well.

JAXenter: What was the biggest challenge that you encountered in splitting up your application in microservices — but from which you’ve learned the most?

Mark Rendle: Developing a microservice system – actually writing the code for the various components – is a huge challenge when you first start. When you’re running and debugging one of the services, you need to have all the others up and running as well, and have request routing and things working. I’ve been using Docker Compose to spin up a full set of services, and got it set up so I can edit my code and have it live-reload right in the container.

JAXenter: You have a polyglot approach to writing different services in different languages. That is very interesting! So why did you want to use different languages?

Mark Rendle: Different languages, and the different frameworks or libraries that are available in them, are good for different things. I’ve been programming for over 30 years, so I’ve learned (and forgotten) a lot of languages over that time, and I’ve never liked restricting myself to just one at a time.

On this project, well, kind of defaulted to C# and ASP.NET Core, but then as I’ve been building something I’ve thought “this would be easier in…” and just done little things in something else. Being able to do that is one of the great things about a microservices/containers approach.

JAXenter: Which languages did you use for what kind of service?

Mark Rendle: Most of the basic stuff is in C# on ASP.NET Core. I’ve built the authentication microsite in Node.js, so I could use Passport, which is an amazing library with tons of plug-ins. I’ve also used Node and Socket.io for any web-socket code in the system. Anything that interacts with Docker is written in Python, which has the best Docker libraries outside of Go, and I’ve used Python for some other orchestration stuff as well. I’ve been playing with Rust for some performance-critical services, although that’s at the early stages.

JAXenter: Let’s move on to another topic: Docker. How did you use it in your application – and what are the main benefits of using a container technology?

Mark Rendle: I’ve broken what used to be a monolithic ASP.NET application down into multiple back-end services and microservices, and each of them run in separate Docker containers. I can deploy and upgrade each and any of them individually on a single Azure Linux VM, which is keeping my hosting costs right down while still giving me the benefits of VM-like isolation. I can also develop in Visual Studio 2015 on a Windows PC, while running the code in Linux containers using Docker for Windows. And of course, the biggest advantage to container-based development is that when a container works on my machine, I can have confidence that it will work on any Docker host.

JAXenter: How do you think Devs should adopt a DevOps culture?

Mark Rendle: DevOps is about taking responsibility for your code from writing to running. You can’t just make developers responsible for deploying applications and managing production environments; we have to change the way we think about and write code for continuous integration and deployment. That means considering your architecture and technology choices, decomposing applications into more easily manageable chunks, and testing at every level from isolated unit tests to full end-to-end integration tests. And of course, it means learning a whole bunch of new things, and hopefully, that makes you a happy coder.

JAXenter: And what’s your advice for Ops?

Mark Rendle: Embrace the change. There are new ways of doing things, and it doesn’t mean devs are replacing ops, just that we’re working more closely together. Building and maintaining the infrastructure that enables developers to get code up and running, from app server clusters to distributed configuration stores to message buses and so on, whether on-premise or in a cloud environment, is a new challenge for Ops teams. Lean into it.

Comments
comments powered by Disqus