The complexity of software architecture has exploded in recent years. The number of tools, methodologies, execution environments, and services that you can incorporate into modern systems grew almost exponentially within just the last five years. If you take a closer look, you'll realize this wasn't driven by technology. The main drivers were continually evolving business requirements pushing established approaches to the limits.
[ Discover ways enterprise architects can map and implement modern IT strategy with a hybrid cloud strategy. ]
An architect is a driver behind successful and sustainable development projects. An architect is also indirectly responsible for team velocity. How can you put more emphasis on the kinds of technologies that help teams perform faster and more efficiently?
Even though DevSecOps and continuous integration/continuous development (CI/CD) pipelines are common now, setting up development environments continues to be challenging. It is a tedious but necessary task that usually happens during project creation. Creating development environments is somewhat documented, but as teams grow, the process is rarely optimized. That's less of a challenge when you're working within a well-defined set of technologies and smaller teams. But it quickly becomes a nightmare when you need more strict governance and as the team grows larger.
[ Learn how to build a flexible foundation for your organization. Download An architect's guide to multicloud infrastructure. ]
What makes up a development environment?
Development environments are usually separated into two areas. One is the inner loop, which describes everything happening on a developer's laptop, and the other part is called the outer loop. Here is a rough sketch of an inner/outer loop setup for a traditional Java project.
Within the inner loop are established tools like integrated development environments (IDEs), build tools like Maven or Gradle, and tools to package and test your services locally. You might even have client tooling for version control or various IDE plugins to secure conformant code and configuration. While this sounds trivial, it turns out to be a lot more complicated. You want to make sure that library and container dependencies are pulled from the correct repositories, and you might need to use corporate templates for code inspection. Tabs or spaces may seem like the least of your concerns. But configuration is critical because it has to be exactly the same on every developer's machine.
With every new piece of technology, the dependencies grow even further. Think about building and running containers locally to execute integration tests for individual services. One major advantage of modern Kubernetes-native frameworks like Quarkus is that they come with support for containers and local tests. With the help of Quarkus' DevServices, you can spin up containers locally for databases and directly test them. But some days, not even this type of convenience is enough, especially when you have to switch between different project settings often.
This is where centralized development environments come into play. One example of this is OpenShift Dev Spaces (previously known as CodeReady Workspaces).
3 advantages of cloud-based development tools
Cloud-based IDEs solve some of the boundaries of local IDEs in several ways. First and foremost, they decouple project environment descriptions from a local installation. This is done with the help of devfiles that contain a complete workspace description. It also allows replicated launches of the same environment for all team members. They enable you to provide a standardized, up-to-date environment within minutes for almost any number of developers joining a project.
Another advantage is that IDEs aren't limited by resource constraints. Spinning up complete clusters with dependent containers for various services may extend beyond the resources available in the most powerful developer laptops. In heavily regulated environments, it's mandatory to work as close as possible to the production environment.
If you're using OpenShift, instead of testing with different container versions and runtimes locally, Dev Spaces can work within the OpenShift platform to keep development as close as possible to the production environment.
[ Download Hybrid cloud and Kubernetes: A guide to successful architecture ]
Third, an important byproduct of cloud-based IDEs is increased data security for development artifacts and the complete environment. This is because everything a developer works on stays on the centralized cluster and corporate infrastructure. Nothing leaves the secure workspace that is governed by centralized access management, no matter where (or on which device) someone is working.
Wrap up
Centralized IDEs like OpenShift Dev Spaces help mitigate some of the challenges of remote work environments, speed onboarding, and limit context switching. These are very important aspects of enabling team velocity and productivity.
[ Become a Red Hat Certified Architect and boost your career. ]
关于作者
Markus Eisele is a Red Hat Developer Tools Marketing Lead at Red Hat. He is also a JavaTM Champion, former Java EE Expert Group member, founder of German JavaLand and a speaker at Java conferences around the world.
