posted on Wednesday, September 08, 2010 3:43 PM
We developers used to be obsessed with optimizations. Like a child with an Erector Set and a whole lot of spare parts, we always wanted to “make it better”. In our case, better was faster and using less memory/CPU resources. Where development came from – a few Kilobytes of memory, a much slower CPU, and non-optimizing compilers, this all made sense. But the rest of IT, and indeed, the business, didn’t want to see us build our Erector set higher, or make our code more complex buy more efficient, machines were speeding up at a relatively constant rate and the need was no longer there.
Flash forward to today, and we have multiple cores running at hundreds of times the speed of the 286 and 386 families, memory that would have been called “infinite” or “unbelievable” in those days, compilers that optimize, the web server and networking layers in front of most apps, and everything from the bus to the hard disk running faster. You would think that the need to optimize was 100% behind us, right?
WRONG
Just as I am rediscovering Erector Sets and their new-new-newest competitors (like the great educational robot kits from OWI Robotics shown at right) with The Toddler, the cycle has completed, and developers are going to find themselves needing to recall how to optimize. While their optimizations will generally be in a slightly different vein than they were in the past – optimizing compilers do a “good enough” job at the things we used to worry about like loops and counters – it will be optimization just the same. Most cloud providers charge you in a variety of ways, including throughput, number of servers, amount of storage, CPU utilization… The list goes on, depending upon your provider, some subset of these will be on your bill. Even if you are internal-only for cloud, the idea that you have X resources and the network is once again going to be the bottleneck is real. The ability to “spin up” another 100 or 1000 instances means your infrastructure – servers and network in particular - is going to have to work a lot harder to maintain performance.
The reason is simple. Cloud services charge by what you use. If your application is high-volume and you use more resources than is strictly necessary, well the Cost of Cloud Over Time indicates that you will have to reduce your expenses one way or another, and optimizing your code to utilize less resources that you’re paying by the month for is one of the obvious choices.
No, I’m not saying that we’ll be delving down into assembler or inlined routines again, that’s what the optimizing compiler and/or interpreter do for you, I am saying that unnecessary network connections, routines that use CPU power and could be written more intelligently, and the bulk that you send over the network in response to user queries will have room for improvement, and your organization will be motivated to take advantage of that room to squeeze extra dollars out of the IT budget.
LOTS TO WORRY ABOUT, BUT NOT EVERYTHING
Storage will have similar issues, but I contend that developers have less control over the storage aspect, as applications will likely only be a small percentage of the data saved in unstructured formats. Databases on the other hand will require the services of DBAs again. The act of optimizing access speed (generally by rolling back from third normal form) and amount of data being stored (generally by utilizing the most intense versions of third normal form) will require experience and forethought. Most developers aren’t specialists in the access patterns of databases, and databases are not yet smart enough to do this stuff for you.
There are non-development ways to handle the network traffic too – at least the bulk sent over the network – via tools like F5’s LTM and WOM that will allow you to reduce the packets or compress the contents of packets, reducing your overall throughput for billing purposes. But for connections that don’t need to be made in the first place? Those developers will have to ferret out. Situations like where you do an NS-Lookup on an IP, and that information is later needed in a different part of the code. Rather than do another lookup it will be worthwhile to take the time to pass the information around or (don’t tell anyone I suggested this) make it global to the application.
It is the nature of Internet communications that it will still be difficult to maintain information over the life of the session, but again, there are solutions, most involving the DB or client-side storage, both of which increase your network usage, but one of the two is probably a necessary evil with the structure of the Internet as it grew up. Note that I said one of the two, not both. In the age of cloud, if you store session info in the DB and send it back to the client, you’re paying double. The debate over which is better has been concluded and re-concluded more times than I can count, Cloud only changes it in the sense that many cloud providers charge you for in/out network usage. If your cloud is internal, you probably only care if you are burying your Internet connection (something products like our WOM and EDGE Gateway are designed to help alleviate).
So think about what you’re doing when you’re doing it, optimize as you code, but optimize with an eye to “is this going to cost money in the cloud”, because the simple optimizations of old are taken care of for you, and your monthly cloud bill could be smaller.
Meanwhile, I’m going to snag the dinosaur erector kit next time I’m at HobbyTown USA, just so it is around when The Toddler is old enough to use it. And no, I have no relationship with any of the toy vendors mentioned, other than The Toddler loves the T3 Robot pictured above.
Technorati Tags:
Cloud,
Cloud Storage,
WAN Optimization,
OWI Robotics,
HobbyTown USA,
Erector Sets,
F5 Networks,
F5 WOM,
F5 LTM,
F5 EDGE Gateway,
Don MacVittie
Related Articles and Blogs
