When meeting new pentacorneses or colleagues from other companies, we often end up with the topic of how we actually proceed with new projects. We are then happy to represent our “colorful bouquet of templates for the fast and secure delivery of new applications.” This often results in a — sometimes more, sometimes less — heated discussion about the usefulness of such templates.
In order to illustrate our template approach and give you an insight into these exciting discourses, we have constructed such a conversation here. In this case, we had the conversation with a random discussion partner — let's call him “John Doe” — at an imaginary meetup. This gives you the opportunity to form your own opinion on this topic.
John Doe: “Hi Penty, we have won a nice new customer project. The customer needs a new API façade in their existing system landscape. Unfortunately, he wants to quickly install an MVP (Minimum Viable Product) fully automated using a DevOps approach on his runtime environment. He is less concerned with functionality and more with seeing the whole thing embedded in his infrastructure. In other words, the classic pitfalls such as network firewall activations, accesses and so on have been clarified. For us, this means working overtime again in order to get this done at such short notice. ”
Penty: “Hi John, it's great that you have a new customer project. However, you don't have to work overtime for this. Just use templates and you'll be done in no time at all. ”
John Doe: “Huh, templates? What do you mean by that? We don't have anything like that. ”
Penty: “So we have a lot of templates that address exactly this problem. For example, we have a Spring Boot template that is fully automatically installed in our development cluster. This template façade covers all the minimally necessary features of an API façade, such as a standard controller, a standard adapter, monitoring and logging. The aspect of the runtime environment is also standardized as a template. We have integrated all runtime environments that were relevant to us so far, such as Kubernetes, OpenShift or PCF (Pivotal Cloud Foundry). When we start new projects with new runtime environments, we also include these configurations in our template. ”
John Doe: “Hmm, that sounds interesting. Does that mean that you always try to solve a new project with the same software stack? ”
Penty: “You can't say that in general. Of course, we want to guarantee quality and stability to our customers. That's why we like to rely on proven practices, technologies, and frameworks. But of course, we also analyse the problem to be solved. And if another tool fits better, then we're not afraid to use it. And if it's still worthwhile to create a template again from this problem solution, then we'll just generate a new template. ”
John Doe: “Ok. How is that exactly? Let's start with DevOps: Problem API Facade. What do you have to do to get a new project up and running for you? For example, the developer goes to start.spring.io And does something click together there?”
Penty: “No, of course not. We maintain our templates in our own repositories. There you fork the required template and, if necessary, adjust the configurations, such as artifact names or packages. ”
John Doe: “Ah yes, and with that, the developer can start and then basically have a locally running Spring Boot application? ”
Penty: “That's right, that's how it works.”
John Doe: “Understood. Now I want to bring the whole thing to Kubernetes and not with you, please, but in the customer's runtime environment. Assuming the network is free and the credentials are there. What's next? ”
Penty: “Then you use the template configuration of the runtime environment. The corresponding parameters for the CI and CD have already been set there. You then expand these with the appropriate configurations of your customer's integration and production environments. ”
John Doe: “That sounds exciting. Are you also flexible when it comes to the location of the repositories, the type of credentials and the number of runtime environments? In principle, could you use Kubernetes in your environment and OpenShift in the target environment or something else? ”
Penty: “We keep this configuration very generic. That's why we don't care about the type of target environment at this point. Repositories and credentials are stored in an outsourced system configuration — this is a separate Git repository for us. We control the runtime environments using profiles, which means that the deployment process knows which profile is assigned to the target environment and picks up the appropriate configurations. ”
John Doe: “Do I understand correctly that you also have a standardized deployment process? How do you do that and what steps does it consist of? ”
Penty: “Yes, we have a standardized deployment process. This generally consists of: code checkout, compilation, unit and module testing, package, system integration tests/end-to-end testing, API smoke testing and deployment to the various target environments. Logically, the deployment will stop immediately if any of the steps fail. ”
John Doe: “Great. It all sounds too good to me. But doesn't this approach run the risk of your software stack becoming obsolete? What is it like when a team wants to try something new — keyword innovation? ”
Penty: “There is a risk, of course. We have tried to address the problem as follows: At Pentacor, we have a group of interested people who meet regularly. This group reviews possible and necessary software updates.
To address the keyword innovation: The template group includes suggestions from other groups in pentacor, which may be looking at extensions, innovations or trends. These other groups are organized thematically. For example, we have a DevOps group or an architecture group, just to name two of many. ”
John Doe: “Okay, I understand, but how do you document what you're doing? ”
Penty: “On the one hand, we use a ticket tracking tool to structure and maintain our tasks and reviews. On the other hand, we have extensive documentation in our company wiki to describe the architecture and use. For example, in our onboarding, we have documented a hands-on that describes how to use and extend the template service. Each new Pentacornese goes through this stage during onboarding. ”
John Doe: “Onboarding sounds pretty good at first, but then it's forgotten! How do you promote communication in your daily work? And how do the other teams find out when you've evaluated something new? ”
Penty: “We have a regular date every week for our project teams to meet. There we talk about new template approaches, results and the like, among other things. We also communicate changes in our dedicated chat channel or via email. And if we would like to discuss a topic in a focused manner with different people and different skills, then we hold a meeting on that topic. If necessary, tasks for the template group will be removed again. ”
John Doe: “Oh dear, it all sounds like a lot of work: creating and maintaining templates, regular meetings, following trends, and so on. You don't even have time for project work anymore. ”
Penty: “Of course, you have to invest in such tasks — both in terms of time and money. However, we have recognized that this allows us to act much faster, especially in project business, and that we are also familiar with much more detail. As a result, this investment is quickly rebalanced. ”
John Doe: “I have to say that actually doesn't sound so uninteresting. I would take one or the other aspect with me and evaluate it with my colleagues. Thank you so much for the insight into your process. ”
Penty: “I'd love to. Just contact us if you'd like to know more. ”
One way or another, a discussion could actually have taken place. We have also had such discussions internally. Of course, we are aware that such a template approach is not a panacea. Every project with us must address various criteria, such as:
- Is it the right tool for the problem?
- Are there any dedicated customer requirements that speak against this?
- Do we have enough time and capacity to try something new?
Based on such questions, it must be clearly assessed whether a template fits here or not. In the end, each project team can decide for themselves which software stack they want to work with — in line with the motto: “Tailor your template.”
We are also always interested in how other companies deal with this issue. Perhaps you will be our next interlocutor? We're already looking forward to it!
