The Adelaide-based Peter Lees told iTWire that the direction the company was taking with its next release, SUSE Linux 15, was to try and become even more modular than at present.
"With SUSE Linux Enterprise 12, we introduced the concept of modules so we could add functionality, so we could improve functionality even between service packs," he said. "Some customers wanted to have the latest development tools or something like that but they didn't want to have to upgrade the whole service pack or wait for it. so we are getting back to this modular approach.
"With SLES 15, we are taking that to the next step so that the very core installer of SUSE Linux is basically very small, a thin layer, and then all of the functionality is added in modules. So you can add the bits which you want when you want them and you can also update them out of band without the stepped service pack releases."
Lees said: "With the same base, we have what we call the SLE Micro OS which provides micro services. That's our container-as-a-service platform. All the commands, all the base functionality is on SUSE Linux, but it is deployed for laying out containers and container systems.
"That changes the goalpost a little bit when you are doing Kubernetes because it's not a system where you can just change one part of the cluster at a time and then make another change and another change. Everything you do has to be done at once.
"So we have introduced this concept of transactional updates which we can do with the Btrfs snapshotting filesystem. We can, in one go, change the entire cluster to be the same version of itself in one hit rather than having to do it in kind of a stepped fashion. Basically we are trying to make deployment and management of Kubernetes a lot simpler. and those are the two personalities of SUSE Linux 15 in the future."
Asked how customers were reacting to this change, Lees responded, "They are very interested. We are finding that a lot of people are interested in the concept of containers and micro-services but they don't necessarily know what that means in detail.
"Today (Thursday, when SUSE held an expert day for stakeholders in Melbourne) when I asked the audience who knows about micro services, only about 20% of the people raised their hands. I think a lot of our customers are interested in finding out, first of all what is all this new stuff that they're hearing about and then how does that all actually work.
"I think we will be answering a lot of those kind of questions. The technology is there to help us but i can imagine that we'll see a lot of people asking 'how do i take my existing application stack and make it more container-based? how do i take advantage of this micro services architecture?'"
Elaborating on the way the system was organised, Lees said: "If you've got some application like a Web application, you might have a Web frontend, you might have the app server, and you might have the database. These are all essentially monolithic applications. Inside each of these, there's a lot of separate functions. Inside the Web server, you might have a login function, credit card function, and so on.
"The idea of micro services is that instead of having all these functions inside a monolithic application — which would mean that you would have to update everything in the event that you want to update one — you break it out to individual services that then communicate with each other by a well-defined interface.
"So it means that if you've got your login and your credit card functions or whatever, the guys who are working on the login functionality can do as many iterations as they want without necessarily affecting the guys who are developing the credit card function. So this micro-services architecture along with agile methodology means that you can iterate through changes inside your system a lot quicker and add that incremental functionality."
He added: "And because you've got these very well-defined interfaces for functions to talk to each other, you can change as much as you want as long as those interfaces remain the same. And then you can add additional interfaces and once you establish those, the other modules can start accessing them. It's kind of like object-oriented programming in a way, but in terms of deploying your services. If you've got these things broken up into small chunks, each doing maybe one or two functions, then the question of deployment comes up: do you deploy them on separate VMs or on separate machines which is not very efficient? That's where containers come in.
"Each one goes in its own container. That lets you establish rules about how those containers can interact with each other. And then when you put them into a networked container system like Kubernetes, you can do various things. Like if you are getting too much demand for one particular service, just create more services and scale up that way. and that's what we are doing, that's why we see a lot of interest in that because obviously it makes this kind of development a lot easier."