Helsinki, Finland is known as a center of technological innovation. Home to mobile phone pioneer Nokia and birthplace of Linux, the northernmost major city in Europe is currently one of the most vibrant hubs of technology startups in the world.
In an office near downtown Helsinki, Kai Virkki and his developers are fulfilling his organization's mission to innovate in the field of IT Service Management (ITSM).
Virkki is the Chief Architect at Service-Flow, a SaaS provider committed to simplifying the way ITSM buyers – many of them financial services companies – integrate their tools and processes with large-scale vendors such as Accenture, Fujitsu and CGI. "We thought, 'What would an integration look like if Apple was doing it?'" says Virkki. "We wanted to offer a ready-made solution that is easy to implement and easy to use without doing so much technical stuff."
Today, Virkki shares his thoughts about how Service-Flow handles the technical stuff by running their software on Stackato, which enables them to "just push" new applications while being able to access the underlying resources at any time.
How does Service-Flow innovate in the IT Service Management industry?
We established Service-Flow to do IT Service Management (ITSM) integrations-as-a-service. We build components called "adapters" that connect to various ITSM tools, and then we offer these systems to our customers. If they are using a certain ITSM tool, we offer an adapter so that we can get the messages out of their ITSM tool and route them to other systems. If everything goes fine, our customers don't see us at all. They just see the messages coming and going between their systems.
Integrations are something that are complicated and often fail. Usually those systems, both the customer's and the vendor's, are quite unreliable. They tend to have issues with network connectivity and it's hard to figure out where the problems lie in typical integration implementations. In some cases, I have seen it take days for companies to figure out, "Who knows something about these connections?" We wanted to be the component that is the most reliable between customer and vendor, and make the integrations and their rules visible.
Our customers outsource their ITSM to big service providers. So it's important for us to interface with these providers, so that when a customer says, "Okay, we are using Accenture for workstation management, and we are using Fujitsu for service desk, and we are ordering new workstations from CGI or a certain provider," we already have these vendors connected. We are building mutually beneficial relationships with these vendors so that we can make sure the integrations are working from their side as well as our customers.
Why did Service-Flow decide to implement PaaS?
My assignment was to figure out what kind of software we should write, how to run it and what technologies to use. I started to look around for what could be the quickest way to get up and running, and that was to have our software hosted and not have to buy our own servers.
That's how we ended up in the Platform as a Service (PaaS) world. At the time, CloudBees offered both a PaaS and a continuous integration and delivery platform. So we started with CloudBees and ran our service there for a couple of years.
Kai Virkki (leaning against pinball machine) with Service-Flow colleagues
What kind of issues did you have using a hosted PaaS?
We were fairly happy users. The biggest challenge was that we didn’t have any access to the servers it was running on. We just built the software and deployed it to their service. But as we were doing integrations, we had some challenges. We'd usually have to have static IP addresses towards our customers because they would have their software running inside of corporate networks, protected with firewalls. And it was also difficult to understand if there were connectivity issues, things like that, because we didn't have direct access to their servers.
The final trigger to look for something else was when CloudBees decided they would move out of the PaaS business. That's when we started to look at other possibilities where we could run our own software.
What alternatives did you look at?
We gathered a long list of possible solutions. We looked at typical solutions like Heroku, Amazon Web Services (AWS) Elastic Beanstalk and AWS Opsworks, but they were missing functionality that we would have needed to implement ourselves. The problem with Heroku was that it was more or less the same problem we had before, but we would have had even less access to the servers. With CloudBees we could at least run some dedicated machines to get static IP addresses, but that was not possible with Heroku.
Another thing was that we didn't want to start convincing our current customers that, "Okay, there's this new hosting company now". They would ask, "Can we trust them?" We've convinced them already that Amazon was okay.
We've been using Amazon for a long time for running different things like databases and file servers. We've had a lot of security-related discussions with our customers. They want to understand in what kind of setting we are running the software, and can they prove it to be secure. And, it has to be running inside the European Union since our customers need to comply with EU data protection regulations. We are able to do that with Amazon (regions and Availability Zones). So, we started to look for PaaS solutions that we could run on Amazon, and that's how we found Stackato.
I also knew about Cloud Foundry before from its connections to the Spring framework that we've been using from day one. Stackato supported Spring and all of our other technology choices, and has worked well for us.
How important was it to choose a PaaS based on Cloud Foundry?
"ActiveState uses Docker within the Stackato product, so they know what's happening in the tech world and are using the best solutions for certain things. It felt like a good future-proof solution."
- Kai Virkki
I wouldn't say that it was one of the most important things. But it was a good thing to have because we had this experience with CloudBees, that we can host our software somewhere, but you never know if that company disappears from the market. That's risky from a migration perspective. So it's good to have some standard, or de facto standard like Cloud Foundry which makes it easier to handle the situation if some risks occur.
That's a great point. What about Docker?
It's an interesting technology, this Docker. We've been looking at it and thinking like, "Will this be the solution, that we would just build Docker images and then figure out some environment where we could just deploy those Docker images and get like a PaaS kind of functionality?" But really, we thought that would be a little bit like going backwards. We don't want to manage servers and infrastructure. We are more interested in deploying our software somewhere, so it feels a little bit backwards to have to build these technology stacks, like, selecting application servers and those kinds of things, as there are already PaaS solutions which do it for you.
But, it was something that we thought, okay, ActiveState uses Docker within the Stackato product, so they know what's happening in the tech world and are using the best solutions for certain things. It felt like a good future-proof solution.
What benefits have you seen from using Stackato?
Well, we use something that is nowadays called microservices. We have tens of different applications that run together and make up the services towards our customers. And we are seeing a trend of further splitting our current applications into smaller and smaller microservices. This would be a lot of work to manage without help from a PaaS. Without a PaaS, it would take us at least a month to develop the number of updates that we currently deploy in one week. With Stackato, we usually deploy tens of applications at a time and deploy updates every day, even many times per day. Plus, we can push to any environment knowing that they are identical to the production environment. So for us, Stackato makes it really easy to manage a large amount of software."
When we started using PaaS, we were able to reduce our development time by 50%, deploy updates without service interruption and achieve 99.999% availability. Of course, when we were moving to Stackato, we were basically migrating those applications. Migrating our existing applications was easy, since Stackato supported our chosen technologies and processes.
"Without a PaaS, it would take us at least a month to develop the number of updates that we currently deploy in one week...Stackato makes it really easy to manage a large amount of software."
- Kai Virkki
There are other good things. Now we get more control of the underlying servers because we actually run the instances on Amazon. So, we can access them and log into the machines if need be, or we can install some specific kind of software that we couldn't do with CloudBees. For developers, it's still easy. They just push new versions. Basically, they build the deployment package and push it. So we get the PaaS benefits, but we also get the benefits of doing whatever we need to do on the command line.
Also, from a customer security perspective, there is only one hosting provider now – one less to worry about. We don't have to convince our customers that ActiveState is a company that handles itself securely and has certain kinds of certificates. Now Amazon has all the possible certificates. So it's more about how we as a company handle our processes, like who gets access to customer data. We can now support customers that require personal non-disclosure agreements (NDA's) for accessing their data, which was not possible before.
How does Stackato help achieve 99.999% availability?
PaaS has made it possible for us to deploy updates without downtime, which is crucial for meeting our availability targets. We push tens of updates multiple times per week.
The zero downtime deployment from Stackato is something that has been really great for this – a way to deploy applications with no maintenance windows even when they are running with only a single instance. When you deploy something, you have the old instance running until the new instance has been started, and then the old instance will be taken offline. We've basically built our deployment pipeline to use the blue-green deployment model, which is well supported with Stackato.
What other technologies do you use?
One of the most important is the MongoDB databases that we use. They are hosted in Compose, a company that used to be MongoHQ. Those databases are also hosted in Amazon. That's also one reason we wanted to have a PaaS that would run on Amazon.
"The zero downtime deployment from Stackato is something that has been really great for this – a way to deploy applications with no maintenance windows even when they are running with only a single instance."
- Kai Virkki
We use Hipchat from Atlassian, where we have chat rooms and get all the auto-notifications from different systems. And we've integrated a log analysis service called Papertrail to our applications through Stackato's Logyard mechanism. It was quite nice to learn from the Stackato documentation that, "Oh, it actually reads here Papertrail. That's exactly what we use!"
And we still use CloudBees hosted Jenkins. We have our build pipelines and deployment pipelines hosted there. We have a longer history using Jenkins, so it was natural for us to use it from CloudBees. We've now built our deployment pipeline from Jenkins to Stackato as well.
We've used multiple other services for different things, like version management and quality metrics. We've gotten them to integrate really nicely with each other.
How many applications do you have running on Stackato today?
Service-Flow's cloud configuration with Stackato, using two public subnets and two private subnets for high availability
At the moment, we have about 60 applications across our Stackato clusters. We have been doing at least one new application per month, and probably will do even more.
Basically, when we start implementing some new system, we usually write it as a separate adapter, and later on we try to generalize these. So first we expand, and then we take some of them away because we find out that certain systems can function in a more generic way, while others are more technology-specific. Some systems are so complex to integrate that it's better to have them as separate applications.
We have two production environments: one is for integrating our customers' and vendors' production systems and one is for integrating their testing or staging environments. And then we have our internal development and demo environment that we use to convince new customers to use us. At the moment, we have three separate Stackato clusters for each of our production, testing/staging and development environments. And all of those are running on Amazon.
What is your current focus and what are your expansion plans?
Currently, our main focus is on expanding to other European countries, like the UK and the Netherlands. We are seeing great success with helping financial companies with their integration challenges. Many of our customers are in this segment.
There are some prospects who are asking if Service-Flow can be hosted in the UK. That's also interesting. Now, when we are using Stackato, it would be much easier for us to establish an additional cluster in the UK, with some hosting provider there. We need to have something that works the same way in different hosting environments. This is a great additional benefit we got when selecting Stackato.