info.michael-simons.eu

Note: Both JFrog and O’Reilly sent me a paper copy of DevOps Tools for Java Developers for review (or my reading pleasure, or hopefully both). The copies came with no strings attached and this article is my honest opinion.

The book is written by Ixchel Ruiz, Melissa McKay, Stephen Chin and Baruch Sadogursky. 3 of them I met personally and all of them come very much from the developer side of things and are known people in the Java world. All of them work at JFrog these days.

The latter is an interesting fact: JFrog is a public company that positions itself these days as the one stop solution for software supply chain management with the punchline “manage your binaries from developer to production”. A (long) while back I got to know JFrog primary for it’s (Maven) compatible software repository solution Artifactory which has evolved into a central solution to manage binaries, container-images and many more. Together with with build pipelines, distribution and a bunch of other things they target the complete requirements of developers and operations from build to production.

On that premise it only make sense that JFrog supports its people to publish about tooling for developers and it’s a great approach reading such a book written by developers.

The introductory chapter: DevOps for (or Possibly Against) Developers

The part really got me quickly. Of course Baruch refers to both the Phoenix Project Book by Gene Kin and others and The DevOps Handbook from the same author: Both are written coming from the operation side of things, not from the developers. So the question is implied: Is DevOps something coming from operation agains developers? Spoilers: It is not.

I really love how that chapter makes it clear that DevOps is very much not engineering per se, but is about collaborations and a shared endeavors. There are no DevOps engineers but site reliability, production, infrastructure, QA and some more disciplines of engineering and together the build an amalgam of development and operations that eventually fosters better quality, produces savings, deploys features faster and strengthens security.

Funny enough in these odd times we are living in: Baruch also addresses the fact that many companies – including modern software companies and not only companies of the past century – are cutting costs at all places. They can do so by layoffs, salary and benefits reductions or by doing better with the same resources, without grinding them down. This is also what DevOps is: Working together.

Contents

The table of contents reads like a proper build chain really. Taken verbatim from here you’ll find:

• (One introductory chapter I covered explicitly)
• The System of Truth
• An Introduction to Containers
• Dissecting the Monolith
• Continuous Integration
• Package Management
• Securing Your Binaries
• Deploying for Developers
• Mobile Workflows
• Continuous Deployment Patterns and Antipatterns

I like that order a lot! It starts with source control and I think it makes totally sense todo so: There are new people to the field everyday and we just cannot assume that everyone has an idea what that is and in addition, I would bet personal money on it that in way to many enterprise organization source control manage is still neglected, even in 2022. I skipped over most the Git specific things, but the history and intend of these topic are written well by Stephen.

Containers and its terminology is ubiquitous but seldom distinctly explained. That chapter by Melissa covers not only the what, but also the way and then the necessary best practices. It’s written in a refreshingly different way than the usual “you must / should do this” approach, either in written words or especially in the style of conference driven development. Excellent content.

What I like the most is how she explained that once secrets and stuff made it into an image, there’s no way to get them out again due to the layered nature and layered filesystem of images. Therefor I am gonna repeat this here: Be careful when crafting your first container image, don’t delay proper secrets management to a later stage.

That monolith chapter by Ixchel: Lucky me, in my day job, I am a library maintainer and can enjoy the luxury of watching the space from the outside. For better or worse. I was consulting in a previous life and have seen the heights of micro service architecture. These days, the pendulum seems to go into the different direction again. I read the anti patterns section closely and I violently agree. It’s good to start with them, especially if you hand this book to a junior person. I’m not so much in agreement with Spring Boot, Quarkus, Micronaut and Helidon being dedicated micro services frameworks though. They can be used in such a fashion, but you can also build (good or bad) monoliths with it. I recommend having an intensive look at the Moduliths effort by Herrn Drotbohm. There’s middle ground (of course, with different tradeoffs).

Can we assume that Continuous Integration (and later continuous deployment) is a given? I am not sure… Hearing how many manual steps it took in companies to react to log4shell back at the end of 2021 I have my doubts. Anyway, I really dig the reference to eXtreme Programming (XP) practices in the introduction of that chapter: “Code integration should be regular and rarely complicated”. If it is, you are already screwed. It goes on further stressing the importance of build and test failures and how they should be easy to investigate and fix. I would like to add that the day you opt to live with one red or one flaky test, is the second opportunity to shoot yourself. And with little surprise, I agree with the scripted builds, too. Nice UIs will only help you so much… And not everyone is equally fluid or able to navigate a UI and it’s pattern.

I did expect a bit more about central solutions in Package Management, but that chapter is a pretty solid introduction to build tools, especially how Maven handles package resolution. It is an important topic, though. Interesting note here is the rather short section about Docker: Here package management is complicated: Docker tags are fluid and prone to change… How to achieve reproducible builds with that? There seem to be no perfect answer.

Securing Your Binaries If you are familiar with any of the previously chapters and think the book isn’t for you, it might still be: Supply chain attacks and everything related to it are on the rise. This chapter by Stephen written together with my long time good acquaintance Sven is an essential read. It starts with the SolarWinds case and takes it from there, covering static and dynamic security analysis, the different roles of different people and many more things and even interactive application security testing and self-protection.

In addition, the chapter includes a proper introduction of the CVSS (Common Vulnerability Scoring System), which comes in quite handy. The section about the fact that vulnerabilities can be combined into different and new attack vectors cannot be underestimated.

The chapter ends with Quality Management and using the Quality Gate method as barriers as well as point of actions for risk assessment, countermeasures and risk tracking. I was a bit irritated for various reasons that “Clean Code” by Robert Martin is mentioned here, but its about making clear that “clean” code (whatever that is anyway) does not cover secure code. I do however disagree that only “clean implementations” opens up the full potential for security measures.

I’m very pleased to see Ana-Maria Mihalceanu in this book, too. She wrote Deploying for Developers. This chapter contains the culmination of several other chapters in the introduction of Kubernetes and how you can programmatically deploy from your build descriptor your application into a cluster, packaged as a OCI compatible container image. Monitoring, Tracing, Logging etc are all covered.

Maybe it’s my restricted experience in that special area, but I miss the mention of one-stop-solutions like Heroku or Pivotal Cloud Foundry of old where many of the things I would need to do for / in a cluster are done for me. Or maybe something like an assessment analogue to “make or buy”. Different tradeoffs, I know, but till to this day, not all applications are Netflix scale (neither in number of clients nor data produced. The latter being relevant in the context of the first chapter that speaks about the explosion of data created in the last years).

I guess a book covering the whole value chain of things these days isn’t complete without covering Mobile Workflows. I did only briefly skim this, though. A proper collaborative effort for being able to deploy new versions continuously is very important in this area: You want to grow and retain your user base with new features, keeping apps secure but also relevant to the algorithm of the app stores. It’s fun to read about device farms in this chapter… A category of problems I have never ran into luckily I guess.

The final chapter Continuous Deployment Patterns and Antipatterns is a logical conclusion of the book. It reemphasis the need for being able to continuously deploy and deliver with both the changed customer aspects and the need to act on security breaches and improving the timeline from identification to solution. The numbers stated about the Equifax security breach in 2017 are staggering (the costs go into the billions).

The case study about the iOS AppStore and how Apple change updating things (in many ways for the better) hits home with the version issue: It’s true that for many applications I don’t even know what version I have… It’s latest. At work there’s an ongoing discussion about that topic but with a database, a tool used as a foundational block for other software, it’s kinda hard to completely omit that information as long as you’ll never have breaking changes.

While all the case studies here are somewhat entertaining they aren’t meant to be, I guess. It can and will eventually happen to most of us.

Verdict

I enjoyed reading this book a lot! It gives – juniors and seniors a like – an exhaustive overview about end-to-end developing applications with the needs of 2022 and beyond in mind. And with developing I mean of course everything that is subsumed under the DevOps term: From actual coding, testing, packaging, deploying and observing with both security and availability and performance metrics in mind.

If you are in a hurry I would recommend at least reading the chapters “DevOps for (or Possibly Against) Developers”, “Securing Your Binaries” and the “Continuous Deployment Patterns and Antipatterns”.