Entries categorized as ‘Technology Strategy’
As we near the completion of a major web application for a startup, it’s time to reflect on the factors responsible for the success.
- Cloud Computing. The hardware cost for development was less than $750. That figure included the cost of a laptop. In an economic climate where startups have to do more with less, how can you beat that?
- We used Google App Engine for the most part but not exclusively.
- For confidential documents, we used Amazon S3, preferring to go directly between the browser and Amazon, bypassing Google. Any doubts about whether Google will mine those documents were neutralized.
- Staying conceptual with the implementation.
- Google App Engine was great for helping us stay conceptual. They take care of scalability, backups, OS versions, patches. All the stuff that drags you down.
- Amazon EC2 is too low level. One has to worry about scalability, backups, OS versions, patches. So we go up a level with Rightscale and BitNami.
- For the same reason, we would consider Amazon RDS over doing our own database management.
- Open Source Software. Most notably, jQuery. Their slogan is “write less, do more”. The reality matches the slogan. A rich milieu of available software allowed us to assemble components rather than write code. A couple of times we were bitten by it too. A month after we had integrated a component, the developer decided not to support it any more. We switched away. So one has to stay agile but that’s the name of the game anyway.
- Staying conceptual with the requirements. This was the second-biggest factor: working with a team that trusts you, things don’t need to be written down to an excruciating level of detail. You hear the requirement in vague terms, you implement it, and if you had misunderstood, well, change quickly. Keeping the Agile Manifesto in mind.
- Tracking shifts in business strategy. This was the biggest factor. The business strategy changed at least a couple of times during the project. The development was continuous, however. We were surprised to discover that the changes forced us to re-factor the code as it was re-purposed to fit the changing strategy — but very little of the code was thrown away. The re-factoring may have made it more modular, actually. By the time the business strategy had settled, we had software components that were well-tested already. Only the final integration was left to do.
Your mileage will vary, of course, but these are the factors that made us successful for this project.
Categories: Customer Relationship · Requirements · Technology Strategy
Tagged: Google App Engine, Building Web Applications, Entrepreneurship, Agile Development, Cloud Computing
What are some of the hurdles we have encountered with Cloud Development? What mechanisms have we used to overcome them? The problems posed by the different cloud platforms are different. I will be writing on this topic in a series blog posts. I expect to blog on these topics. If you know of others, please let me know. These list items will get hyperlinked over time.
- Cloud Development for Google App Engine
- Cloud Development for Amazon EC2
- Managing software delivery from outsourcers
- Managing evolution of database configurations
- Performance and Stress Testing
- Security Testing
In this introductory post, I want to cover activities that cross all platforms. The premise of Cloud Development is that the company does not own any hardware. Under these circumstances, how does software development get done? (more…)
Categories: Requirements · Techniques · Technology Strategy
Tagged: Agile Development, Amazon AWS, Cloud Computing, Cloud Development, Entrepreneurship, Google App Engine, Issue Tracking, SaaS, Source Control
The good news with Cloud Computing is that our clients don’t have to sink precious capital into building or finding a data center or buying servers.
The bad news — at least the concern — is lock-in. Is a business locked in once they have grown? Do we have choices in case Amazon (or whoever) decides to raise their prices? Will the customers be able to take their business elsewhere if that happens?
There are a number of vendors out there providing cloud computing services:
- Amazon, of course.
- Rackspace
- GoGrid
Others will follow. IBM has made announcements regarding Cloud Labs, Microsoft is working on Azure, etc. But I want to focus on Amazon, Rackspace and GoGrid in this post. They offer services that are somewhat analogous, each has the equivalents of S3 and EC2. (more…)
Categories: Technology Strategy · Technology foundation
Tagged: Amazon AWS, Building Web Applications, GoGrid, Microsoft Azure, Rackspace, SaaS, Software as a Service
February 12, 2009 · 1 Comment
The force is with virtualization — hosting as many of your applications on as few machines as possible.
We have seen this movie before. Client-Server was all the rage when web technologies came into vogue. All of a sudden, we didn’t have to visit every desktop to “do an install”. Once the trend got going, the cost savings became quite compelling. It took a number of years but eventually most of the applications were rewritten to be web centric. The installation problems moved from user desktops to the company’s servers.
Virtualization is the next step in that continuum. The cost of managing your applications on your servers is getting felt and, slowly but surely, applications are getting SaaSified. They will probably need to be rewritten, just like they were in the transition from Client-Server to the web, but that will take time, effort and investment. The venture guys are reluctant to fund a new company unless it is a SaaS company.
What I don’t know is whether the economy is helping the trend or hurting it, which is why it is difficult to assess when SaaS will become the dominant trend. It might be helping by creating the pressure to reduce cost. It might be hurting by reducing overall investment. Time will tell.
What does it mean for early stage companies? (more…)
Categories: Technology Strategy
Tagged: SaaS, Software as a Service, Virtualization