Fodder for Friday


We only have a few weeks left until we welcome 2016, so with everyone already sitting back to enjoy the holidays, we thought we’d make it easier for the tech community to keep up with what’s important and happening by feeding them a little fodder every week.

These articles have been hand picked and contain a small gist revealing a glimpse of what the story is largely about. Well, yes, you can thank us generously – we always welcome chocolates, pies, cakes.. well you get the point!

So here goes:

Best Practices for Usability Testing (bitovi)

These practical, useful tips to weave usability testing within the design process should help agile teams build it and ship it, all while getting users to test it as well.

Stories of SaaS Success 

4 SaaS companies. 4 different people. 4 different approaches. Yet, 4 acts of brilliant successes.

Buffer is Perplexed with Social Media

This one’s ironical. After an honest admission of confusion as to why their social media sharing is declining, Buffer’s founder Kevan Lee got 390 comments and over 2000 shares for his article.

Key Lessons from Volkswagen

The VW issue has clearly pointed out the false sense of security under which we have been operating for a while when it comes to the networks, hardware and software that we rely on for IoT. Read on…


What Metrics Are Important when Talking Continuous Delivery

The cloud revolution and the subsequent ‘As-a-Service’ economy has been wildly successful primarily because of the attitude of continuous progression. You don’t find enterprises saturating when they reach a status quo; instead you find them continuously exploring ways to automate processes, access meaningful data, and advance self-learning capabilities in a secure, trusted environment.

At Qruize, we’ve been toying with continuous delivery and we’re going to take a deep dive into some related topics a while later. For now, we want to make our readers understand continuous delivery and what metrics make sense when deploying often, faster.

Continuous Delivery – What is it?

Continuous Delivery is a set of practices and principles aimed at building, testing and releasing software faster and more frequently. This allows us to do three things: Deploy more often, get feedback, and fix problems, all much faster than before.

Here’s a rule of thumb: you’re probably doing continuous delivery right if your software is deployable throughout its lifecycle. Now that we’ve got the basics out of the way, we can move on to the juicier details.

How do you measure the success of Continuous Delivery?

Everyone relies on data and metrics to measure success. Logically, the software development process can’t be improved upon unless the change implemented is quantifiable. It is no wonder that strong development teams are metrics-driven. However, the trick is in identifying what should be measured. The metric to be monitored for determining success/failure is bound to have a significant effect on team behaviour as well.

For instance, if lesser lines of code are seen as a positive metric, developers will write many short lines of code. If success is measured by the number of defects fixed, testers will log bugs that could be fixed with minimal effort, and so on.

The bottom line is, there is no point in removing bottlenecks that aren’t actually constraining the delivery process. This is why it is critical to rely on a global metric to determine if the delivery process as a whole has a problem; and for software delivery, that metric is cycle time.

Cycle time and such

In its barebones, cycle time is the time elapsed between moving a unit of work from the beginning to the end of a physical process.  Dave Farley and Jez Humble who wrote the book ‘Continuous Delivery’ define it as “the time between deciding that a feature needs to be implemented and having that feature released to users”.

How long would it take for an organization to deploy a change? And what about when this is done on a repeatable, reliable basis? Cycle time, the time it takes between deciding that a feature needs to be implemented and having that feature released to users is hard to measure because it covers many parts of the software delivery process—from analysis, through development, to release.

There are ways around the difficulty – a proper implementation of the deployment pipeline helps in calculating parts of the cycle time associated with check-in to release. It also reveals the lead time from check-in to each stage of the deployment process – thus baring bottlenecks.

External Restrictions and Other Parameters

Sometimes, the bottlenecks playing havoc on your cycle time could be external. Subordinating all other processes to an external constraint may be the only viable option, therefore, while the CD process runs along smoothly, deployments could be slammed.

A way around this has been to record not just the total cycle time but also the number of deployments into each environment which offers an efficiency metric that pinpoints where the issues were and record how our work affected them. Some other diagnostics that warn of potential problems are: number of defects, velocity (rate of delivery of tested, ready to use code), number of builds/day number of build failures/day and duration builds among others.

All in all, selling continuous delivery is a combination of visibility, risk mitigation and responsiveness (cycle time) of the development team.

DevOps versus NoOps and the future of PaaS

We’ve been working with dozens of customers who come up to us with unique problems: and we often help them in unique and effective ways whether it has to do with building a platform or migrating applications to the cloud. A common misconception with most organizations we come across is that migrating to the cloud makes them agile. While a significant selling point for the cloud is the agility angle, simply being on the cloud won’t make you so.

Organizations want to bring applications to the cloud and manage them in the cloud

In our previous post, we spoke at length about the DevOps movement which has enabled organizations to shrink months-long procurement cycles and develop the infrastructure they need in a matter of hours, or even minutes. At first glance, we can all agree that some traditional ops activities are starting to fade away:

  • With IaaS in the picture, we no longer need to rack servers in house or swap hard drives ever.
  • PaaS does away with configuring firewalls, installing databases or web server software.
  • Configuration management and automation frees us of manually installing applications, patches or publishing ssh keys.

While many organizations have benefited from this automation, greater gains can be realized when the application development and hosting platform provides capabilities further up the stack. In other words, more abstraction is essential to derive more value out of cloud computing.

The way to do that, thereby making the lives of developers easier is through PaaS – decoupling applications form the operating system. In essence, DevOps and PaaS represent two different paradigms for delivering applications to the cloud.

  • DevOps – DevOps takes an automation approach – the process of installation, configuration and deployment of the application stack are scripted
  • PaaS – PaaS works by abstracting the details of the cloud infrastructure from the developers


While this may seem like developers could do away with Sysadmins once and for all, typical Sysadmins argue that they can grow up to 75% of PaaS functionality with DevOps tools like Chef without giving up any systems architecture flexibility.

The NoOps Movement

“[With PaaS,] instead of having one hundred different problems, now you can have one hundred times the same problem,” said Jérôme Petazzoni (@jpetazzo), Tinkerer Extraordinaire for Docker.


In his blog post, Adrian Cockcroft, director of cloud systems architecture for Netflix, detailed having little need for operations staff, partly because the company shifted to the cloud, thus automating former functions. In another instance, PaaS provider AppFog, has argued that the emergence of PaaS offerings eliminates the need for most operations within the organization, thus enabling a NoOps culture. AppFog’s infographic regarding this stance was published on GigaOm.

It is pretty obvious now that NoOps often gets linked with PaaS. However, we have already established that PaaS cannot and will not “solve all problems” and “enable blissful ignorance”. Several experts including James Urquhart and John Allspaw have agreed that cloud hides certain kinds of problems, only to replace them with new and more interesting ones. AWS, Heroku or Azure could have outages. The PaaS platform can’t magically scale applications if there is IaaS congestion. If another SaaS service is leveraged for an app, we’d still be constrained by the operational excellence of said service.

Melding DevOps and PaaS Together

However, the answer isn’t choosing between once of these seemingly competing paradigms. We don’t need to. Simply make DevOps the foundation of your PaaS infrastructure. This way, Sysadmins can provision any services – choose their stack, pick their cloud and package the entire thing as an environment for the developers to work with as a black box. Handing up a significant part of the operational responsibility to developers makes it even more imperative that the PaaS is infused with operational tools pre-baked by the Sysadmins. Thus the Control of DevOps and the productivity of PaaS, rolled into one is critical to business agility and operational efficiency.

DevOps + PaaS

DevOps + PaaS

In fact, with cloud computing, the role of the Ops is not going away but it stays in the background offering an interface which developers can manage themselves. The symbiotic relationship between DevOps and PaaS only serves to transform infrastructure into an abstracted application layer that stands ready to initiate services on demand.

Docker to the Rescue!

Docker is the new kid on the block that is rehashing the application development scene in a big way. Why, because unlike VMs and hypervisors which take a lot of memory and file system space for virtualization, docker containers share the kernel resources with all containers. This means there’s no bloated, unwanted code/libraries in your package. You can now focus all your creative energy into getting your application experience right while docker does all the heavy work in the background.  It has made application development as easy as Build, Ship, Run. Docker containers do everything else.

The architecture of a docker container is different from that of a Virtual machine instance. A VM abstracts the entire operating system from head to toe. So if you run multiple VMs on a single box, you have multiple such abstractions – result, unwanted loss of memory and infra. Whereas, docker containers package all the necessary files/codes/resources within the container itself and only depends on the shared kernel for execution. This means there’s a substantial decrease in system overload, speed is much faster, applications are responsive and reliability is much more predictable. But all things in life come with a fine line right? Though docker has accelerated DevOps in a big way, there is a limitation with containers in that they run on the same OS only. You can’t have multiple OS emulations on the same box. But when it comes to running more applications on a server, than having more server types, it’s the former that wins and this is why most of the financial companies/ data warehousing/hosting companies are making a beeline to reap savings right from the start. Containers are also safe and secure, they are easier to maintain as well. Docker knowing this partners with other container enterprises like Canonical, Red Hat to build safe and secure containers that are easier to maintain and deploy.

In a day and age where enterprises are struggling to make applications and workloads more portable, Docker introduces a sure fire way to make applications work and run virtually anywhere and without any assistance at all. And the best part, containers love the cloud. So it’s now an easy thing to deploy stuff using containers on the Cloud as well. Docker works with most DevOps applications like Puppet, Chef, Vagrant, Ansible etc. Docker simplifies most tasks that other applications do for example, setting up multiple live servers within a local instance, test projects across different server settings, deploy for multiple operating system etc irrespective of the local host environment.

In closing, Docker just accelerates application development, managing and deploying applications. It helps developers to quickly create and deploy containerized applications on the fly. This would just excite just anyone who’d want to see cost savings go up.

From DevOps to Business Agility – What is needed?

DevOps – Widely Misunderstood

What really is DevOps and why does it have the technical community jumping through hoops?


Some people have come to believe DevOps actually refers to highly skilled developers who write all of the code and deliver the application to production single-handedly. Others confuse it with continuous delivery, automation, and sometimes even configuration management. There are plenty of misconceptions about the definition of DevOps and a quick search can reveal what DevOps is not.

So, in an attempt to define DevOps let’s see it for what it is: a methodology, a set of concepts, a movement in itself today – to building better teams and better software. DevOps is slightly different from a Sysadmin in that themes revolve around creating and assembling infrastructure as a code as opposed to the ‘manage and adapt’ roles assigned to sysadmins who ensure vendor purchased items run optimally.

The problem stems from the fact that the different teams within a substantial development project don’t understand the work of other teams. Business analysts, architects, UX designers, testers and developers have all lived on their own islands and none of the development specialists, until recently, have worried about the production environment when designing or developing applications.

So now that we understand what it is, we can find out how it is useful and what it means to development teams.

The Numbers Speak for Themselves

It seems that the processes, tools and decisions of development teams have a significant impact on the quality and predictability of a software release. Hence, it is only logical that when compared to traditional Ops, DevOps is a clear winner. Numbers from a Zeroturaround DevOps report prove this:

  • Compared to Traditional IT Ops teams, DevOps-oriented teams spend 21% less time putting out fires on a weekly basis.
  • Compared to Traditional IT Ops teams, DevOps-oriented teams spend 33% more time improving infrastructure against failures.
  • Compared to DevOps-oriented teams, traditional IT Ops teams require nearly 60% more time per week to handle support cases.

In January 2015, RightScale surveyed 930 technical professionals across a broad cross-section of organizations about their adoption of cloud computing. Here’s some of the findings from that survey:

  • Overall DevOps adoption rises to 66 percent, with enterprises reaching 71 percent.
  • Chef and Puppet are used by 28 and 24 percent of organizations respectively.
  • Docker, in its first year, is already used by 13 percent of organizations with a whopping 35 percent of organizations planning to use.


It is apparent, with the rosy picture the numbers have painted, that DevOps as a cultural methodology and technical concept is a definitive win for most organizations. How painful the DevOps transformation is going to be depends on each business though.

Planting the DevOps Seed

The implementation of a DevOps culture into any organization requires an updated approach to the ways that organizations process data. The technical side of things have made great strides: this is obvious from Vagrant, Chef, Puppet, Amazon, Docker, Packer, JHipster, Selenide and dozens of more tools & technologies being used and embraced by a growing population every day.

So what’s really missing and what can organizations do?

  1. Culture Handshake

Operations can ‘work upstream’ and identify the coming changes that might cause issues way before they are due to hit production. More importantly, they can contribute to solving the more ‘cultural’ issues such as instrumentation, the types of performance, resilience, and scalability testing that minimizes production risks.


While the developers work on the deployment, they also need to be able to do customer support from time to time. Some devs need to know why their idea is or isn’t so great to customers. Many also need to actually know and understand how the customers use or want to use the systems.

2. Establish DevOps Blueprint

Engaging CxOs to remove barriers for DevOps and providing direction is crucial. Business units where the dialogue with customers frequently changes and where the IT organization will need to iterate rapidly for new product ideas, markets, and customers are ideal candidates for agility and DevOps. These may be pilot projects on the roadmap to future opportunities.

3. Emphasis on Design for Automation


Automation, especially for testing, configuration management, release management and other delivery steps are essential. It is a key ingredient which will impact continuous delivery and DevOps productivity.

The most logical entry point to transforming business process in any organization might be customer-facing IT services. Customers expect an evolving relationship with service providers that hinges on understanding their needs and preferences. IT has come full circle today, it has the potential to bring about business transformation. Agile development, with cloud computing and DevOps centric approaches will ensure business agility.

Three years in style..

The idea for Qruize was born intuitively, when our co-founders identified the need for a research-oriented approach to software engineering and new age technology adoption. In the span of our eventful journey, this core idea, seeded into our ethos, has germinated, and has branched into new business lines and product launches.

So, on the 3rd of July all of us – Qruizers, our families, clients and partners huddled together to celebrate our 3 years of incorporation. We have been able to create a mark and a name for ourselves in such a short span of time and we thank our well-wishers, clients and investors for making this a reality.

The event- held at the Madras race club had around 120 people who spent the evening with us. The event started off with a lamp lighting ceremony followed by Selva, one of the principal founder’s,  welcome address.

We then had Ezhil, our CEO tell us in a brief but concise way what Qruize is all about akin to a consultant in the technology space. He broadly also touched upon the future roadmap of the company as well.

With that it was time for celebrations. A huge cake was cut with “Qruize 3 years” written on top and was distributed to all.

Click on the picture to zoom

Click on the picture to zoom

A special musical program was done by Mr. John Vijay John – Manager of Marketing and Communications. He enthralled the audience with 2 songs. Both songs were well received by the audience. There was a special section for the kids who were busy and happy with as their favourite characters came to life on their hands and face. There was also a special trampoline erected outside the hall for the energetic souls as well.

As a token of appreciation to long standing employees, gifts were given for people who completed 2 and 3 years of service with the company. Mr. Sabapathy – consultant for Qruize did the honours of introducing the candidates for the gifts. We hope many more will follow in the years to come.

Most importantly, we launched QruizeInfra, an amalgamation of cloud implementation services, cloud optimization, managed services and desktop virtualization. Simply put, a customer can completely rely on QruizeInfra to design and implement cloud architecture and gain visibility of their IT infrastructure as a whole. This transparency can reduce the time they spend on IT infrastructure management. The brand new website is up and running – you can take a look at it to gather deeper insight on our offerings.

We’d like to think that Qruize has made a significant dent in the cloud space in India and we’re poised for the long road ahead. We cherish the good thinking, and the energy generated by our employees’, clients’ and partners’ enthusiasm. To put it simply, we aren’t here to look backward but very much to look forward.

Qruize Technologies at CDN Asia 2015

On May 12th and 13th, CDN Asia returns to Singapore for its fourth edition, to explore opportunities and emerging trends in media content delivery. We, at Qruize are super excited about this. Arun, our business solutions strategist is part of a panel discussion as well as a roundtable discussion at CDN Asia next week!



Co-located with


The numbers of broadband subscribers and mobile users are ever on the rise especially in the APAC region – serving some of the biggest opportunities to service providers and cloud operators.

Arun, on 12th May, will be part of the interactive debate on the Opportunities & Risks for Operators in Cloud TV. The primary focus of the debate is on monetizing the move toward Cloud TV, effective business models for investments in cloud and CDN infrastructure, CDN virtualization and the impact on content delivery through cloud.

If you are a content/technology provider in the CDN space, talk to us about partnering or reach out to Arun: