[From the last episode: We looked at how micro-servicesSmall programs that do things that, in an earlier time, would have been done within one large program. Breaking them out into smaller programs that then act as services to other programs makes them more robust and easier to maintain. can make complex programs easier to manage in the cloudA generic phrase referring to large numbers of computers located somewhere far away and accessed over the internet. For the IoT, computing may be local, done in the same system or building, or in the cloud, with data shipped up to the cloud and then the result shipped back down..]
When we talked about micro-services, we mentioned a couple of benefits, one of them being that it’s easier to do an update on a small piece of functionality rather than a huge program. Let’s look at this more closely.
Depending on your age, you may remember a time before softwareIn this context, "software" refers to functions in an IoT device that are implemented by running instructions through some kind of processor. It's distinct from "hardware," where functions are built into a silicon chip or some other component. was delivered over the internet. When you purchased software, you got a bunch of disks or CDs – whatever the best physical medium was at the time. So… what would an update look like then?
Updates, Old-School
Well, there probably wasn’t an update. If a company wanted to update all customers, they’d need to ship a new set of disks out. This did happen, but it was a big deal, and, usually, the update wasn’t simply mailed out – you had to ask for it. The equivalent today might be moving from Microsoft Office 2013 to 2016. It’s a whole new set of programs, and you replace one with the other.
These releases tended to come infrequently because they were a big hassle both for the software companies and for the users. The software companies had to do all kinds of testing to make sure that the new versions worked – both the new parts of the software and the old (to make sure they hadn’t unexpectedly broken something). And the users had to find the time to do the update (maybe uninstall the old one and sit there feeding CDs for a while) and then check to make sure everything was still working with the new release.
There were ways of doing partial updates, but those tended to be fraught – you were leaving major portions of the programs in place and replacing select small library pieces called dynamically linked libraries, or DLLs. Those DLLs might be shared between programs so that if you updated one for use in one updated program, it might break another program that hadn’t been updated. The affectionate name for this nightmare was “DLL hell.”
Holding on to the Old Version
For more specialized programs, it could be even worse. There are giant, complex programs, for example, that designers use when creating a siliconAn element (number 14 in the periodic table) that can be a semiconductor, making it the material of preference for circuits and micro-mechanical devices. chipAn electronic device made on a piece of silicon. These days, it could also involve a mechanical chip, but, to the outside world, everything looks electronic. The chip is usually in some kind of package; that package might contain multiple chips. "Integrated circuit," and "IC" mean the same thing, but refer only to electronic chips, not mechanical chips.. Each chip project could last six to eighteen months, and there was likely to be a new release or two during that time. The problem for designers is that they do the design, lock a bunch of things down, do more of the design, lock that down, and gradually move to being finished after they’ve spent lots of time making sure that speeds are right and that they followed all the rules and all kinds of other things.
If they were almost done with the project and then the program were updated, it might change all kinds of things that they thought were done. It might not necessarily break them – maybe they were still fine. But they had to prove that they were still OK, and that meant redoing all kinds of things that they thought were already put to bed. The solution was to version-lock for that project: they weren’t going to take a new version of the software for that one project. When starting the next project, then they might start with the new version – and lock it for the duration of that project.
Updates in the Cloud
This all makes sense in a world where you have physical control of the programs and they’re running on your computer. Cloud computing has changed all of that. You’re now running programs on someone else’s computer, and they – not you – have control. And this has created a big change in how software releases are handled.
Instead of shipping new releases out to us, they simply update the programs themselves. That makes life much easier for everyone. They can update small things frequently rather than having to gather everything up for one big update. Sometimes they’ll change something – and have some people get the update before everyone does. This happens on social media platforms – your Facebook might look different from someone else’s for a while. This let’s them test to see if it’s clean – they can do a quick revert back to the older version if there turns out to be a problem. They can also test two ways of doing things and see which works better for the users. Eventually, everyone gets the selected update.
If they were still working with big, giant programs, then they’d still have to do lots of testing to make sure that some new thing didn’t break some other old thing. But by taking these big programs and splitting them into smaller micro-services, each micro-service is now independent of the other micro-services, so there’s less testing required and fewer things to break.
Agile and DevOps
There are two major philosophies that have evolved from this gradual change. One is the notion of doing small changes or developing small features very quickly and releasing them often. If they don’t work as desired, then go back and change them again quickly. Rather than update schedules being every year or so, we’re talking doing something over a week. The key word here for the industry is agile. If you want, you can get into a long, heated debate about what “agile” technically means; I’ll spare you that here. Hopefully the general idea is clear.
The other philosophy involves how organizations work. The old way is that you have a group of developers that write the software, and, after it’s released, there’s a bunch of IT folks that load it onto the cloud computers and manage it there. The two were separate groups – development and operations – and they didn’t work closely together. Development would toss the new program over the fence to operations, and then they’d start to work on the next thing. If operations had a problem with the new program, they’d have to bug the developers for fixes, distracting them from their new project.
The new way brings the two much closer together in a way that allows developers to react much more quickly to any needs identified by operations types. The industry buzzword for this is DevOps. Yeah, I think you can see what they did there…
Note that this still poses a challenge for folks like silicon designers that don’t want their programs changing without their approval. Those sorts of cloud computing then become more complicated, since you would need to have multiple versions of the software running in the cloud to handle the various version-locked projects using them. This isn’t a particularly common thing yet, but it could become so.
An Agile Bakery with DevOps
We used a grocery-store analogy last time, and we can use it again here to reinforce these two trends. Let’s say that a big grocery store has a new bread that they’re offering from their bakery, and they want to advertise that fact. There’s a monthly newsletter and marketing program that publicizes things from the store and issues ads and coupons. Every department wants a piece of that, so the bakery needs to get onto the marketing radar so that they can be in the media in a month or two. Not agile.
With a separate bakery, they control their own ads and messaging, and they can put the new bread out and see how it does, cancelling it or modifying it if necessary to suit customer tastes. No negotiating with a big corporate marketing team. They can be agile.
In addition, let’s say that the big grocery store has a central bakery where they experiment with new ideas. Once new recipes are available, the individual store bakeries can start to make them. That central bakery might be in a different state or even a different country, so if the local store wants to provide feedback, it’s probably hard to do. Development and operations are too far apart.
With a single independent bakery, the people trying new things out are just in the back room, and if customers have something to say about some new product, then the salesfolks up front can simply tell the folks in back. Development and operations are working closely together.
Leave a Reply