Prerequisite: If you are unfamiliar with Kubernetes be sure to attend: Understanding Kubernetes: Fundamentals
Aha moments with apps in containers can be quite liberating. The mobile space is saturated with “there's an app for that”. For us, we now expect “there's a container for that”. “Write once, run anywhere” (WORA) has changed to “Package once, run anywhere” (PORA). As the community of containers and flavors is riding up the hype curve we will look at some of those top aha moments together.
• Go rouge with Java 9 and jlink • Polyglot microservices • RabbitMQ broker in 1 minute • Private Docker hub in a container • Kubernetes, it’s all containers • database flavors for integration testing • R engine in 30 seconds • Tomcat with a war, in a container
The epiphanies are in the simplicity. Leveraging namespaces and using cgroups, these apps share a common kernel without polluting the host OS. This eliminates installation, conflicts and uninstalls. The barriers to getting something running are decreased and normalized to a container run command. This is subtly powerful and liberating. With this simplicity comes complexity such as shared resources, file systems, mounts, networking and overall cluster management.
As an example we will peruse the heart of this, the Dockerfile. See how containers can be stacked on top of base images. We will explore the syntax, optimization, tips, best practices and some tricky points such as the difference between CMD and Entrypoint.
Your software package delivery and installation is no longer an rpm, deb, dmg, jar, war, native executable or a run script, it is simply an image that has a common run container command. Liberating.
Lastly we will explore how containers can help and hurt your team if you are not careful. What goes into a container is a reflection of a team's skills. Should a team make each tech stack different, or should you standardize? External processes affect your tech stack choices inside your container such as static code analysis, code beautifiers, CI/CD, tracing, logging and monitoring. Exercise caution as standardization and frameworks can lead to coupling. Your tech stack details can change from version to version so get your SemVer and API versioning right. Finally, containers can be a vehicle to introduce new technologies to those that are conservative and risk avoiders.
The end of the presentation will explore containers driven from this source.
Jonathan Johnson is halfway into his second score of engineering commercial software. Software has the amazing potential to improve and even save lives. Sadly, lousy software can miss this potential. His journey is driven by delivering helpful software to move us forward.
His applications began with laboratory instrument software and managing its data. Jonathan was enticed by the advent of object-oriented design to develop personal banking software. Banking soon turned to the internet and enterprise applications took off. Java exploded onto the scene and since then he has inhabited that ecosystem. At 454 Life Sciences and Roche Diagnostics, Jonathan returned to laboratory software and leveraged Java-based state machines and enterprise services to manage the terabytes of data flowing out of DNA sequencing instruments. As a hands-on architect at Thermo Fisher Scientific, he applied the advantages of microservices, containers, and Kubernetes to their laboratory management platform.
Now, his architecture voyage sails with the symbiosis of Cognituum's Artificial General Intelligence (AGI) platform with the Kubernetes ecosystem.
Jonathan enjoys comparing and sharing his adventures with peers. He shares ways to modernize application architectures while adhering to the fundamentals of high modularity and low coupling. A longtime resident of Connecticut, he discusses his experiences with technical groups and meetups. You will often see Jonathan schooling and retooling on the NFJS tours.