Share with friends and colleagues on social media

SUSECON sign

 

The recent SUSECON in Nashville had hundreds of great sessions, including 11 on SUSE Cloud Application Platform. The one I was most looking forward to was by our partner, Adfinis SyGroup AG, telling their early adopter’s story about implementing SUSE Cloud Application Platform for the Swiss Federal Government. In addition to attending their session, I was able to sit down with Nicolas Christener (CEO/CTO) and Lucas Bickel (Software Engineer) and have a long conversation on about it.

Can you tell me a little bit about Adfinis SyGroup and the type of clients you serve?

NC: Adfinis SyGroup was founded almost two decades ago. It was formerly two separate, independent companies—Adfinis and SyGroup. Both were founded in 2000, were interested in open source, and wanted to bring it to the enterprise market. In 2012, we merged them together to be able to tackle bigger customers.

That was actually around the same time we started looking into enterprise products offered by SUSE as well as Red Hat. For us, collaborating with multiple vendors is the right strategy for being able to deliver just the right solution to customers. We ended up with many different large enterprise customers and all are really happy with our expertise in the field of open source. Nowadays, we have various small customers as well as some huge ones. We’re quite happy with our broad customer base and we are still sticking with that open source focus like we did in the beginning. We are currently about 55 employees and still growing. We mainly focus on Switzerland but also have some customers that are international—for example, there are some big pharmaceutical companies in Switzerland that we work with. One of our key success factors is to be experts in the open source field and have an independent view of the SUSE stack and the Red Hat stack and then really being agnostic and recommending the best solution for a customer’s environment.

So, what do you focus on to help your customers? Application development, IT infrastructure, or…?

NC: We actually focus on four key areas. The first is engineering where we build solutions with open source technologies. This is mostly done with a stack from SUSE or Red Hat. Customers approach us and want to have an SAP Hana cluster or a container platform that is somehow connected to their LDAP or something like that. Integrating with their existing workloads is often a big part of the engineering aspect.

Besides the engineering aspect, we often end up providing managed services, which is our second key area that we focus on. We cover the offerings that we built with 24/7 services, doing monitoring and maintenance to make sure the offering is always up and running. These are two quite important areas for us.

The third key area is software development where we help to build solutions on top of existing open source libraries or applications. Customers approach us and say we have this nice open source technology that’s part of our toolchain. Could you help improve it by adding feature X? So, we don’t have our own product. It’s mostly tailor-made development for customers who want something specific on open source.

Last, but not least, the fourth key area is the DevOps style of doing things where we help customers get that mentality implemented with their team. We can bring our development and operational expertise and help customers build new IT processes with solutions from the development space.

When you’re working with your customers, when is the point that there is a need for a product like SUSE Cloud Application Platform or Cloud Foundry in general?

NC: It’s quite interesting to see a shift in the whole industry. A couple of years ago, we started to build more legacy environments. Things like an Apache web server or a SAMBA fileserver or whatever. That was key to the business back then. In the last couple of years, we see this whole movement of bringing workloads to the container space really starting to grow in Switzerland including in enterprise environments. We started to look into Kubernetes three or fours years ago already. We figured out it was so disruptive that we would really have to focus on it in the future and help customers transform their workloads. Right now, we’re seeing a lot of demand in this regard. To help shift existing workloads and also build new workloads and applications on those stacks. It’s a huge demand. A lot of companies really try to get their foot into this. Our consulting expertise, together with our knowledge of the open source stack SUSE provides, really helps our customers achieve something meaningful in a short amount of time.

Is it more likely that a customer would ask you to deliver workloads as containers, or is it more a case of you recommending that to them?

NC: It’s actually both. For example, Lucas is involved in writing an eLearning platform where a lot of open source technologies were involved as well. That’s our perfect kind of project because we could pull in the Nextcloud stack for a file offering, we could pull in Rocketchat to offer communication capability, and then on top of that our developers wrote an eLearning platform with Python, Django, and Ember.js. It was clear from the beginning that we would build that with containers and that’s one solution where we really developed a solution for a customer and we could decide or help to get them in that direction. There are other projects where we really heavily influence the customer and tell them, “The stack you’re going to implement would be perfectly covered by Kubernetes and Cloud Foundry so let’s do it together and we’ll be the guide or the helping hand to actually achieve that.”

What led you to investigate SUSE Cloud Application Platform / Cloud Foundry versus just running containers in Kubernetes? What were you looking for?

NC: I’m not sure exactly where our journey actually started. There were different routes to that conclusion that Cloud Foundry could be a very, very good solution. One of the important ones was that Kubernetes itself is not too developer friendly. If you really have to solve the needs of a developer and help them get their job done, and doing their magic, then you want to have something like (Cloud Foundry’s) cf push. You don’t want developers to have to mess around with the details of Kubernetes. I think this high level approach, this accessibility that Cloud Foundry brings in is the key for the platform. And that’s probably the biggest part of our decision to use it. Maybe Lucas has something to add?

LB: There were some existing Cloud Foundry workloads that were on HPE Stackato that needed to be supported going forward because HPE is dropping support for that. Especially in the enterprise market, that was a factor that played into this.

That’s interesting! So, you were looking for a replacement for Stackato in many ways. Did you look at other Cloud Foundry distributions or consider upstream Cloud Foundry?

NC: Yes, we looked at a different commercial Cloud Foundry distribution at one point—Pivotal—, but it was just too big and difficult. It was going to be quite a heavy investment. We do have big customers but most of our customers are from the small/medium enterprise sector so they want something slick and small that is not too expensive from a capex and opex perspective, so it wasn’t really a perfect fit. The same also applies to a hosted Cloud Foundry distribution. We initially had a focus on Kubernetes itself, so when SUSE started to containerize Cloud Foundry and talked about Eirini-style Cloud Foundry, it was a perfect way to bring those worlds together.

LB: Also, working together with a vendor that actually understands open open was certainly something that appealed to us because working with Pivotal is okay but they’re just not an open source first company.

Yeah, big parts of their platform are not open source whereas everything we include is.

LB: Exactly.

As big open source proponents, did you consider running open source Cloud Foundry and maintaining it yourself?

NC: No, no. We’re too small to operate that ourselves. We wanted to have support from a vendor and same also applies for our customers. They know that we can do some magic, but if we were to be the ones that operate and maintain their platform code, we would not be big enough. It’s always good to have back-up like SUSE.

Is that a similar story for everything you use, including Linux?

NC: Yes, exactly.

I’m curious if there was a cultural component to implementing SUSE Cloud Application Platform. What was involved in pushing them to accept such a big change in process?

NC: It’s a big cultural thing all the time. We started doing a lot a of training at customer sites to teach them what a containerized application is, what it looks like, how it behaves, and what a stateless application means. We really have to prepare the groundwork for that first. And that’s similar with most of our customers. There are always some team members who already know about this because they learn about it on their own in the evening or whatever. But the largest percentage of the people who are going use such platforms really need a helping hand. It can be a hard thing to prepare and teach them how to use the platform. There are some customers who are leading in this regard, but many of them really need the help.

LB: Often, much of this is really not a technical thing. It’s also about the paradigm shift within the organization itself. They need to realize that they should have a cross-concern team. Often developers sit in one room and now they might need to adapt their existing processes to scale up to accommodate this new release cycle that we might be pushing. If you’re in an enterprise where you’re used to having three deploys per year, you need to address all stages of the process. It’s not just the developers and the ops that need to realize this, it’s really up to management to open up the possibility that we can even be so agile.

NC: And also opening up some technical aspects like letting the container platform manage the storage devices or manage network devices. That was a no-go a couple of years ago. Everyone who wanted to have an open port or something had to go through a really long process to get that done. Nowadays, you just deploy something and the route will be implemented automatically for you. That is part of a bigger cultural change as well.

How do you typically approach that with a customer? Bottom-up, top-down, or a bit of both?

NC: Adfinis SyGroup really is a technical company and we tend to be good when we talk to the technicians and engineers. So for us, it’s usually a bottom-up approach. We try to get the management and decision makers into the loop quite early, but often we don’t have an open door at the C-level–especially with bigger organizations. Going from the bottom-up works quite well for us. For C-level contacts, we have our partners who tend have this kind of connection.

LB: When it comes to moving to the public cloud, I feel it’s often more of a top-down approach because you really need to have top level executives on board from day one if it’s going to be a success.

What challenges do you have unique to Switzerland with regard to public cloud usage and are there restrictions with private industry versus government?

LB: I’d say it’s more or the less the same with government and private customers. The thing is the government does have rules that they can’t go on the public cloud because there are no datacenters in Switzerland yet. Those are getting launched soon so we’re expecting some adoption there to make it easier. Most of the time, at least in the enterprise sector, it really boils down to asking them if they’re already using Office 365. If they do, that means they usually have highest management writing and storing strategic documents on Microsoft servers. Once they understand that and they bridge that gap, it’s clear to them that their developers could be doing that as well.

NC: I also think that Switzerland is a bit special in many regards in terms of adoption of public cloud offerings. Europe itself is a bit behind in terms of adoption compared to the States and adoption in Switzerland is probably even smaller than the average in Europe. It has something to do with our legacy. We have been and still are a big banking country where data privacy is really important and was top of mind. I think that’s hindering adoption in Switzerland a little bit. We’re seeing that change and people are starting to think about adopting the cloud. Microsoft as well as AWS and Google Cloud are options now, but it takes time.

LB: One thing to also consider, especially with regard to banks, is they are really early technology adopters. Way back when, those were the first mainframes that were installed and some of those systems are still in continuous use today. It just takes quite a while because once you are in production, you really need to plan how you would switch something and it’s often much more comfortable to just stay on what’s working. The whole never touch a running system thing, and even in terms of security, if you want to build an air gapped system, then there’s not much reason to do live patching. The Chief Security Officer maybe signed off the system five years ago and it’s still okay because getting a sign-off on something new and dynamic will take lots of time to prepare.

Now that you have SUSE Cloud Application Platform installed and running, what benefits have you seen and what benefits has the client seen from it?

NC: Time to market really is the main thing that improved a lot. Managing storage and network through Kubernetes APIs for example helps a lot. It took time to get approval from all the teams involved to get that in place, but now it really helps to ship new things fast. Another thing is that there is more standardization and more automation and more ability to audit through the platform. Our pharmaceutical customers, for example, really love being able to see what is going on, who did what, etc. It’s so much easier with the interconnected automation solutions inside SUSE Cloud Application Platform. Another benefit is the flexibility of being able to run different environments with different library versions which was a problem in a legacy environment where you had fully patched and tested machines and you can’t just install a newer Java version because it’s not part of the repository stream. Now, with containerized workloads, you can mix and match. That’s a very, very nice feature that is part of the solution.

LB: At some customers, I see that they really like to be able to use a very small base OS in their containers. It just uses so much fewer resources. Things like SUSE’s MicroOS or Alpine are things that our customers are constantly asking us about. I’m hoping that there will be a shift to just having binaries in a container without much OS. Like, what’s possible with Go where you just build one static binary and you can deliver that. The container really can’t get much smaller. This really helps with high availability because it’s much faster to start.

Does that also tie in to doing functions as a service at some point?

NC: FaaS is on our agenda and we will look at it, but it’s not something that is much of a topic in Switzerland right now. It’s much like the (lagging) public cloud adoption – we probably need one or two more years. How is adoption in the States? We often hear that some organizations in the States are already doing it. Is that true?

I’m not sure it’s true that many people are actually doing it. I mean, there’s going to be a few examples, but I doubt it’s widely used.

LB: I think it really ties into the public cloud thing, because the public cloud vendors are the ones that are behind serverless and functions as a service. I think once the public cloud adoption is there, people will start looking at those technologies.

It does seem like an efficient way to get the smallest containers with the least amount of code that someone could possibly want, while being able to re-use things.

LB: Yes, and also being able to scale some workloads down to zero when they’re not used is one of the really interesting use cases when you have an app that’s only used once a month or three times a year. You don’t need to have a whole bunch of VMs continually running for that.

NC: I’m just not sure if it’s disruptive enough to make a big change. It would be a nice feature to have, but I’m really not sure if market adoption will be huge.

LB: We’ll see.

I won’t ask about blockchain…

NC/LB: Laughs.

I’m wondering if you help evangelize within your own customers to bring additional developers or departments on board with the platform?

NC: Yes, we try to bring teams and customers together in many different ways. We have customers in Switzerland who compete with each other, but still come to meetups that we organize. We really like to help get ideas spread and help developers to talk about what they’re doing and get new ideas from other teams. We really like to help those teams to get together on neutral ground. Since Switzerland is really small, it’s fairly easy to get those teams together. Sometimes the topic might be something about HashiCorp, for example, or containers, or Kubernetes or whatever. Those meetups happen quite often. We also bring customers together in projects. Lately we had different Swiss government offices who were working on more or less the same things, but didn’t know about each other. Bringing them together is really beneficial for us as well as the customer.

LB: Inside the enterprise, I think it just takes time for other teams to realize, especially because decisions often need to go through management. Once we deliver a platform, it can take a year or so to see the financials and prove that the new platform with containers is actually very fiscally interesting. That’s the point where other teams in the enterprise will have managers who will want to hop on and get cheaper compute, for example.

How would they justify the cost/benefits to management? Is it more in terms of improved time to market, where “time is money”?

LB: Yes, but it could even be just plain subscription or licensing costs. If you need a really large stack of VMs just to deploy one small application, you need to order and pay for a full VM. Even though you need to pay for a subscription for SUSE Cloud Application Platform, it’s still cheaper in the long run, because you need less of it and it’s easier to share.

Do you do accounting like that for customers to help demonstrate the value?

NC: It sometimes helps, yes. We had some situations also where customers found out themselves that they could save money with the platform, or it was faster. Two days ago, one user wrote a letter to their upper management saying, “Thanks to the platform’s automation, we could save three months of time for deploying something.” It’s really different. From time to time we have to show them, but often they figure it out on their own.

Where do you see this going over time? Do you think you’ll get more customers using SUSE Cloud Application Platform, or expand usage within existing customers?

NC: I think container adoption just started to really go through the roof. Many new customers will need a solution. I also assume that as soon as you have the platform, it will incrementally grow in every organization. I think there is lot of opportunity around SUSE Cloud Application Platform, especially since it is agnostic in terms of the required Kubernetes stack. That is one really, really nice selling argument in its favor.

LB: Yes, and also the fact that containers have been the buzzword for many years, we see situations now where management is telling their teams that they should be using containers. Maybe they heard it from some industry magazine or something, but now they’re telling their developers to use them. For us, that’s great.

You mentioned earlier that you were excited to hear SUSE Cloud Application Platform was adopting Project Eirini. Why was that?

NC: I was quite surprised when I was attending the Cloud Foundry Summit EU in Basel six months ago—I was at a table where people from SUSE and IBM started to talk about the containerization of Cloud Foundry and also using Kubernetes as a scheduler for the containers. I had never heard about that so I really tried to understand what they were talking about and asked a lot of questions. I realized there was something really interesting going on. So, we learned of Eirini there and then started to dig a bit and figured out, “Ah, this is what’s going on behind the curtain!” It immediately became clear that this was going to be a big thing, so we started discussing it with customers. It’s a brilliant idea and it brings the whole Cloud Foundry project to a new level in my opinion.

LB: I think it’s also safe to say that SUSE was a big part of why we realized that this was going to be the future. Looking back at that Cloud Foundry Summit, I think 3/4ths of the entire Summit didn’t realize this was coming. There were maybe two or three techies who had it on their slides. For everyone else, it seemed to go over their head. Knowing this was coming from SUSE really helped us be ahead of the pack.

 

 

 

Share with friends and colleagues on social media
Tags: , , , , , ,
Category: Banking & Finance, Cloud Computing, Containers, Containers as a Service, DevOps, Government, Kubernetes, SUSE CaaS Platform, SUSE Cloud Application Platform
This entry was posted Wednesday, 17 April, 2019 at 4:29 pm
You can follow any responses to this entry via RSS.

Leave a Reply

Your email address will not be published. Required fields are marked *

No comments yet