In my last job as a software developer, I worked on two big projects. One was to create a specialty product for a scientific testing lab. Among other things, the system would allow you to document the lifecycle of the product going through the test, including testing results. Since the product required some pretty advanced reporting, the product not only needed to have a user-friendly interface for the scientists but a slick reporting tool that integrated with software elsewhere in the company.
The other product I worked on allowed our R&D team to search internally written scientific articles and even notebooks since the 1950s. That was an exciting project because we had to scan in all sorts of material, quality control the character recognition, and find interesting ways of displaying diagrams and notes written into the borders of paper books.
The age of monolithic applications
At the time I was writing the testing application, there were no good web-based frameworks and tools available to do everything the scientists required. Therefore, I had to write the application in Visual Basic (ugh!, but cool at the time). Since the scientists all worked in a lab and computers got in their way, I wrote the application to run on a single computer. It used Microsoft Access for the database and reporting, and everything else was my VB code.
Once you design screens for a software application, it all looks kind of easy. You develop the screen, you create a field for each data entry item, and you connect them to the database. In theory, yes, that does sound easy. But then you get into coding, and you realize people need to enter the data with their login. You need to create database connections that use a username and password that might change now and then, you need logging to check when errors occur, and the list goes on. I had two developers including myself working on the code for about four months.
As developers, we tried to break out each other’s code, so we did not step on each other. One person would work on the data entry screens, another would work on database design, and another would work on business logic. However, it was not that easy back in those days. The concept of shared code (or object-oriented design) was only just becoming a thing, and Visual Basic had a lot of limitations.
Very often, we would test our code independently and then when the customer received it. We constantly found that one developer would process business logic one way and another developer did it another way. You would open a data entry screen and type a result, then you would run a report and the result looked different. Any time we made one change, we would break five other things.
Nowadays, people would refer to my application as monolithic. Many things made it monolithic:
- One large code repository where all code and all references had to be managed as a single unit.
- Not automatically scalable to a wider audience (in my case, we had to re-architect the whole app when more scientists wanted access in other facilities).
- No common APIs (application programming interfaces).
- A database diagram that attempted to enforce business logic, rather than letting the application handle that.
A peek at the future of applications
Compare that multiple-month, multiple-developer team to my web-based search engine project (side-note: still in use today, more than 16 years later). The application was a simple web-based solution, offering a single search bar (ala Google, but Google wasn’t around then) and a few helpful tips that showed some advanced query capabilities.
I used a web-based search engine that was freely available. I configured the web server only to allow certain people who were from a specific security group, and all my application needed to do was make sure it properly manage the browser’s state, some cookies, and provide some UI elements to allow for tag searching (author name, publication date, etc.).
The hardest part of that project was to find the right company to scan and tag our scientific notebooks in the format we required. That process took almost a year, but the software development took one developer (me) and two months of part-time work. Of course, I still had testers, training, and infrastructure folks, but it was quite straightforward.
Containers, Kubernetes, and security
While bleeding-edge at the time, my little search engine project showed me a bright glimpse of the future. The idea I could write a code on a server, write the code for a web browser that is separate from the business logic, and use freely available frameworks was a brand new world.
Cut to today and it is obvious that this process of separating your code into separate, manageable units is the best way to develop code. Sure, people can still screw up one thing, and a whole bunch of other things break, but now you can have lots of developers coding on various aspects of a product because it is not just one giant repository of carefully managed code.
Today’s developers are writing APIs, so there is one set of business logic that always produces the same result. Unlike my search engine application of old, it sat on a server and was eventually moved to a few virtual machines. In today’s world, you place your code into containers that are like little mini virtual machines that only run the code you need without the hassle of managing an underlying operating system.
The concept of containers is a relatively new phenomenon, popularized by Docker. Since all your product’s code can be contained within dozens, hundreds or even thousands of containers, they require orchestration, which is where the popular Kubernetes technology comes into play.
Back when I wrote those two applications, my product passed a security review with an email stating only people in specific security groups could access them and that the software did not break our antivirus tools. In today’s world, your applications need many layers of protection. A negative outcome from container-based applications is developers often give the containers elevated security levels, making it easier and faster for them to get the code out the door. Those developers are not maliciously writing insecure code, but malicious actors will find those holes and use them as an opportunity to compromise your systems.
So how exactly do you keep the spirit of Agile development all while making sure your application — made up of hundreds of mini virtual machines — is secure? That is what Kamal Shah from StackRox is addressing for his customers.
Join Kamal and me as we talk about the world of containers, Kubernetes, and reducing the security blast radius in modern applications.
