Building Large Systems
Building Large Systems
JCrete 2014
Building Large Systems
| Building Large Systems |
|---|
| Convenor: Kerstin Buchacker |
Participants:
|
| Summary:
A large system in this session is understood as a heterogenous system, usually not web-based or implemented on a virtual stack, but including often many different off-the-shelf products as well as custom-developed parts in different programming languages. The original focus was on the difficulties of how to build such a system, but was extended to deployment and maintenance aspects as well. Such systems have a lot of issues which are no longer encountered in pure Java or JVM based systems, where the build environment can be tightly controlled through use of artifact repositories, defining dependency and library versions, and classpath settings and quality is ensured through automated unit tests, automated integration tests (in a virtual environment), and deployment can also be automated (web-based or virtual).. Issues encountered when building large systems:
Currently it is much more common to have a web-based system. For upgrading a web-based system, you don't need to provide a distribution, which the cusomter/user then installs. You can just deploy an update or new release. Facebook, for example could change a library without affecting the users at all. If you provide a distribution to the customer, you don't have the ability to change something after releasing. You'll have a user base running different versions of your software product. You'll have a lot of users who don't want to migrate to the new version. How many different versions do you want to maintain in parallel? How do you ensure that you can stil build the older versions? How can you re-instantiate the build environment for the old versions? If your developed product is integrated with many different off-the-shelf products, which you deliver together with your product (possible with open source and free software products) migrating to newer versions of the off-the-shelf products may have a ripple effect and turn out to be a lar ge effort. What will you do if one of the products you use is no longer maintained? How easily ac n you migrate to a replacemnet product?Do you know if all those off-the-shelf products will affect one another? And if yes, how? Similar problems may arise in products, which are extensible with plugins, which may affect each other. Whether to use open source or not is often a company preference. It may be difficult for engineering departments to get the money for commercial solutions. Open source also provides a sort of safety net as you can become the owner of the code (you do have to be careful with the license). In case you use open source, you may decide to maintain the product yourself. This may well cost you quite some extra manpower, which management has not calculated for. You may also want to try to get the maintainer of the open source product to include you fix. Depending on your relationship with the maintainer and whether or not your proposed change fits will into the product vision, it may or may not be included in a future release. For closed-source commercial products, you may have a support contract with the vendor which could allow you to request support and bugfixes. How responsive the vendor is again depends on your relationship with the vendor (e.g. preferred partner or just normal end-user). Controlling (native) library versions is more of a problem on Windows than on Unix, as Unix can handle the existence of different versions of the same library and a software product can choose (during compilation and later during runtime) which version to use. In addition, on Unix you can set the search path for native libraries. It is unclear how this works exactly in Windows. It is good practice, to always define the versions of the libraries in your build. It may help, if you use small dependencies from open source, which provide just a very limited and specific functionality, instead of using one large dependency which provides everything. If problems arise with a dependency, it may be easier to replace a small one with specific functionality than a large does-it-all dependency. For Java applications one usually packages everything (i.e. including any libraries required) into a single a jar/war. That way you are sure you have everything in the right version.intelliJ Idea freezes the JDK and provides an internal JDK to ensure the correct JDK version. In principle, one could also deliver native libraries together with the application and (at least on Unix) ensure that the application uses those packaged libraries. On modern platforms like .net, handling different versions of the same library seems still to be a problem. In .net you don't even have a classpath! If you need to maintain several product versions in parallel or the same product version but on top of different dependency versions, you will need very good revision control and branch/merge practices. It could be an option to maintain patch-sets for different issues instead of branches, which you then apply to your source code as needed. For enterprises which do retail the whole ecosystem consists of a lot of different systems. These all have to communicate in some way. There will be a mix of old and new applications, and web-aware and non web-aware and a lot of glue to bring things together. The products used are implemented by different teams, and it is important to coordinate changes across teams. Clear interface descriptions are especially important here. Microservices can be used for flexibility. |
| Recommendations:
No recommendations provided. |
