Tackling cloud application problems ranging from user authentication to deployment has pushed Austin, Texas-based...
software engineer Karthik Gaekwad to build skills in most development platforms, from Java to Ruby on Rails, Microsoft Azure to Amazon Web Services, and manual to automated authentication tools. Before becoming senior Web engineer at Mentor Graphics Corp., an embedded hardware and software design and consulting firm, Gaekwad held similar posts at National Instruments, Modular Mining Systems and Scientific Technologies Corp. He shares his experiences with cloud app development tools in this Q&A.
Karthik Gaekwad: Right now it's Amazon Web Services (AWS), but I've also done stuff in Windows Azure before. I like AWS. It provides an infrastructure, so you can pick and choose whatever software you want and deploy your apps there. Windows Azure has made sense in some use cases, such as trying to write out C# applications. The nice thing about Azure is you can manage it from one central source or one central point. Azure is a lot more platform-y and not as much infrastructure-y. With a platform already behind the scenes, you didn't need to worry a lot about the super level of things like how the operating system of this box or the security of the operating system and things like that.Which cloud development platforms do you use the most and why?
In use cases where [we used Microsoft Azure], we were trying to send measurement data to the cloud. So, the app was written in C#, and it's a lot simpler to hook into Azure from a manageability perspective than to write a lot of the infrastructure for Amazon specifically.
Which programming languages do you use when writing cloud applications?
Gaekwad: I started off with Java and used it a lot when I worked for National Instruments; both Java and C#. When Azure came out, it was initially optimized for writing applications in C#, so we branched out to write some of our platforms in C#.
I'm sure that Java is not going away.
Karthik Gaekwad, cloud developer, Mentor Graphics
Now, I write a lot more applications in Ruby on Rails and Python because they're so dynamic and tuned for Web-based applications and services. One of the big differences that I've noticed between the Java and .NET stacks versus Ruby and Python stacks is that it's a lot simpler to deploy Ruby and Python applications. Being able to deploy code quickly to cloud apps is highly desirable now. An example of this need is when you have an app that's running and you need to scale it very quickly. Typically, it's a bit easier to deploy quickly with Ruby or Python as opposed to Java or C#. That isn't to say that you can't deploy pretty quickly in Java and C#, but you may have to write a more code. You can automate the process on any language, but there are [features] in Ruby and Python languages that fit well with Web and cloud apps.
Well, Ruby certainly gained from being the first platform supported by Heroku.
Gaekwad: Yes, Heroku is a good example of a Ruby playing field, as it is a platform for cloud applications. When Heroku first came out, if you had a Ruby app, you could do a deployment immediately to a cloud-based platform. You didn't have to worry about the managed length or the management perspective at all, because Heroku takes care of that.
That was years ago, of course. Now, you can do the same thing with Azure, but writing a Windows application and deploying it to Azure still takes longer to do than Ruby or Python plus Heroku. Of course, behind the scenes they're both automated, and you can do the same thing across different languages, but deployments typically go faster with one of those dynamic language stacks.
What are challenges you've experienced when deploying applications to the cloud?
Gaekwad: It's not hard to deploy an app to the cloud. The hard portion is when you get to doing continuous deployment with that big zero-downtime requirement. I recall, a few years ago, it came out that Etsy was doing multiple deploys a day without downtime. That was an eye-opener for the whole community, because Etsy is a large company, so why can't everyone do it? There's been a lot of work since then to not only just measure how much downtime you have in your infrastructure due to deployment, and on writing more tools to be able to get to zero downtime.
In working with cloud application security, what problems have been consistent headaches?
Gaekwad: I've been developing cloud-based authentication and identity management tools for a few years, and I know there are always hackers trying to get in. I wrote user and password authentication systems when I worked for National Instruments. That was a key focus because authentication is a big worry. Users create accounts. You store password and user data in a secure way. So, you have to be sure to correctly validate if it's really that user logging in or that stored user data, among other things, is vulnerable.
A software engineer has to do everything possible to make sure hackers don't get to data. It's obvious that usernames and passwords should be stored in a safe place, encrypted or hashed, but I've seen engineers put these things in logs and have these log files sitting around with username and passwords in clear text. Someone doing user authentication for the first time or second time usually ends up making this kind of mistake, and all user authentication and password or identity security work just goes to waste. If a system is compromised, log files are a first place hackers will look.
Luckily, there are more automated tools for cloud app authentication now. Apache Shiro was a big step in the right direction. The project leader for Shiro has developed a more extensive, automated security tool, Stormpath, which I demoed recently for the Austin Cloud Users Group. The new automated tools help automate all the user creations workflows and cut out a lot of repetitive work and mistakes.