After completing a round of series D funding last summer in which they got an investment of $55 million, CircleCI, a company that builds continuous delivery platform for software developers, announced they will be using part of the money to make an expansion into Europe and be closer to customers across seas. Speaking to DevOps Online, Jim Rose, CEO of the firm, discussed what the move will mean, why they chose the UK and with a plethora of experience, gives advice to those in the industry.
What can you tell us about your expansion into Europe and what it’s going to mean for your firm?
We’ve been doing this for about 8 and a half years and we work through a “bottom’s up” motion where we allow developers to use our platform for free and get familiar with how the firm works. When they are comfortable they start to pay for us. As a global firm, here in Europe, we have about 20-25% of the business. [The move] is to get closer to the customers and as we get bigger, we are trying to build teams to get closer to these customers, help them along and help answer their questions without making them stay awake to speak to someone in California.
Why did you choose to move to London specifically?
Of our European customers, the UK makes up about half. We already have lots of big and interesting customers over here and so we had natural gravitation into London, to begin with. It’s a big and sophisticated technology hub here in Europe and globally and it’s a great launching point as we head into other markets and so it ended up being a really good fit for what we are trying to do.
How do you feel Brexit might affect what you are trying to do?
We thought about our expansion and Brexit, but given the size of the UK market and the amount of customers we have in the UK, we are always going to have to have a presence here. I think the question for us came down to, how are we going to support the rest of Europe? We already have a number of developers making a footprint in the rest of Europe and so if we are in a situation where we need to support that, then that’s what we will do.
EMEA General Manager Nick Mills adds:
Although there are questions where London and the UK will stand in tech because of Brexit, it clearly hasn’t been a problem in the past three years since Brexit was decided. London still is 2.5 times the size of any other tech hub in the region and is still growing. There are strong reasons for that. There are strong developers… There is a strong ecosystem, particularly around venture capital start-ups…combined with investors… and that community isn’t going anywhere. There might be ways in which you choose to set up your company, but luckily, we are already pretty established and have a lot set up to be able to capitalise on the growth.
Will you be partnering with anyone in the move?
We are coming in directly and have a pretty good relationship with the customer. Our plan is to work directly with developers as we grow.
In terms of tech, what kind of tech do you use that enables your firm to work the way it does?
We are cloud-native at the core, so we were really built for the cloud-based world. We use a multitude of different clouds to be able to support that. Testing itself to be able to help and build different software tends to be an extremely spikey business, people tend to see the tests at the same time and then go dark when they are not working. We tend to be indicative of the big trends in terms of software development. We are big Kubernetes users, we are big fans of all the various hashicorp technologies. We have written in a bunch of crazy languages. We tend to be fairly out in the edge in terms of pushing technologies and seeing where everything breaks. I was talking to somebody who said, “it’s really easy to find technologies to do ten things at once, but once you start doing things a million times at once, everything gets a little more challenging”. So, we are one of those types of companies.
Particularly thinking about things like software testing, which points do you think are most important to focus on?
The core part of the CI process generally is to test small batches often. So, you want to be able to test small batches when you can and as frequently as you can. Because it both allows you to identify when something breaks, you know where to look, and the more often you test, the more stable your build gets. Testing’s a muscle, the more you exercise it, the stronger it gets. That is really the heart and soul of a continuation project. Once you have established your overall build, the next logical step is continuous delivery. Because if you can build it and test it and you know everything is good, you might as well get it into the hands of the customer as soon as you can.
What we are seeing more and more is a big move towards microservices. So, an idea of taking your big monolithic apps and breaking them down into individual live services instead of having one code base that’s servicing your application stack. You might have dozens, if not hundreds of services, that essentially, co-ordinate themselves and work together on an application. As you start to move into that world, testing across services is both complicated as well as incredibly important as you now have to make sure that all the services can work in coordination to make sure they can deliver whatever it is you are working on. The more and more services you have, you then have to test those services in production. The idea used to be… that everything should test the same. But when you get into these microservice environments, you no longer can produce a facsimile of your production environment because all these services are moving in different services and in different ways. Many companies now complete actually complete the testing process in production… and that requires a different set of skills but as more and more people head into microservices, I think that probably going to be the predominant pattern that you will see.
Is this something that your company is doing?
It’s something that we do internally, but it’s also something that we support on behalf of our customers. We are really agnostic to the type of technology and architecture that our customers use. If they build big monoliths, fine, if they use small microservices, we can support that as well.
What’s your advice on how to improve a team?
From a team perspective, the idea of microservices really runs hand in glove with agile development and team sizing. So, the idea is that teams tend to work best when [there is a smaller team]. This is the same when it comes to software in that the bigger the things get, the harder they are to test. When you’re getting smaller teams, you’re getting smaller services. Your application starts to mirror the way teams are constructed. However, as you get into microservices, what becomes incredibly important is ensuring teams are working off the same sets of tools and the same baselines. Regards of what kind of teams you are trying to set up, you want to be able to centralise and standardise the way a service gets set up. So, they are using the same tools, the same controls, the same standards and they are using the same patterns.
With all your experience, what are the best pointers you give?
It all depends on where you are as a firm. Using core CI practices are good in terms of testing frequently and testing often and test in small batches. The second is to adopt cloud-native if you can. Also, focus on the thing that makes you special.