Skip navigation

Category Archives: technology

We live in an age of unparalleled opportunities. The cumulative disruptive influences of internet, mobility, open source software and cloud computing have brought down the cost of starting a tech startup to an all time low.

Its been about two years since we started Althea. Starting a company teaches many lessons. I started living what I had read about in many books. Entrepreneurship is no spectator sport.

Below, I try to quickly articulate some thoughts and lessons that came in handy. Primarily from a technology development perspective.

– Leverage & embrace open systems [include open source, open data, open apis & open platforms]. Push open source initiatives that lead to reduced costs of development and ownership. Always resist the developer urge to build everything from scratch.

– Focus all proprietary development efforts towards real innovations & adding value. Ensure that all significant development efforts are tied to a business case. While stop gap solutions can get you started, you need to carefully choose your role in the food chain and supply significant value there.

– Innovate continuously and drive the changes in your space. Build and maintain a sustainable advantage that keeps you ahead of the curve. Become the thought leader in your area of specialization. Remember, innovation today is commodity tomorrow. Your competition is going to copy your ideas and catch up with you shortly.

– Stay ‘truly agile’ and adapt constantly to the changing landscape. Accept the fact that disruption is inevitable, and make embracing it a part of your ongoing plans. New business models are getting conceptualized and tested everyday.

– Treat employees as unique individuals and not as replaceable resources. Capitalise on the unique abilities of each person and deploy them appropriately at different phases of a project. Also, startups win by putting a lot of responsibility on young people and letting wonderful things happen.

– Invest heavily on tools and infrastructures that lead to an increase in productivity. While startups dont operate with infinite resources, they succeed by building small but highly efficient and focussed teams. I remember Charlie Munger quoting “The company that needs a new machine tool, and hasn’t bought it, is already paying for it.”

Advertisements

@BenParr (Co-Editor of Mashable) asks – “POLL: Will iPhone, Android, or another platform be the dominant mobile OS five years from now?”

Smartphone OS wars

Smartphone OS wars

The question should probably be rephrased for the smartphone market. Android’s approach, in many ways is similar to that of Linux, infact its even been built on Linux. They even tried to sneak some code into the main linux kernel tree and got flamed for it. It may even be appropriate to include Linux (given Android + Maemo + others) in the list as a candidate.

While Android’s open approach undoubtedly helps, it also greatly benefits from Apple’s stringent approval process and anti-competitive protection for its own apps.

Despite the dust raised by the Android Developer Challenges, it has failed to capture consumer imagination the way iPhone has. In many ways android’s increasing market share reminds me of ITRON‘s claims to be the world’s most popular OS because it powered many mobile phones, digital cameras, CD players and countless other electronic devices.

Sun Tzu would have said Android spreads like the water. Being an open platform, it definitely finds it easier to morph into a wide range of products/devices. This also leads to a fragmented market. For the same reasons, it was always painful to develop mainstream apps for Linux targeting a larger audience. Plus the additional complexity due to diverse devices. Hopefully, the Google backing helps with some of this.

At Althea Systems, these platform wars keep us on our toes, while we choose target markets for our products (right now Shufflr) built on our social video discovery platform, ShuffleFeed. We closely follow developments in multiple device & market segments without taking sides.

When most people are either confused or like being confused, it helps to put things plain and simple.



Service Oriented Architectures [SOA] play a pivotal role in today’s Enterprise Systems. Service orientation requires loose coupling of services with the underlying technologies. There is a lot Web Oriented Architectures gain by taking the SOA approach, especially with regard to aspects like scaling and being cloud ready.

I dont use SOA here to mean XML web services, but as a pattern for breaking down applications into distributed software components (which we call services). The components being independent units that deliver specific functionality. Data is encapsulated and made accessible only through well defined hardened interfaces. Consumers of the service are provided with a contract for the functionality provided through the interface. Hence, a clear isolation of functionality and data storage is achieved. The services manage all data internally and never provide direct database accesses. Whether access happens as XML/JSON or over REST/XML-RPC/SOAP is irrelevant for SOA. They form the various implementation options.

SOA also provides operational advantages in terms of the break down of the development work. First, small teams are created around problems. Next, the interfaces are decided and agreed upon. The teams then have full freedom in choosing tools, design methodologies, etc., as long as they provide the promised functionality through the interface. Developers in the team own end-to-end responsibilities for the service and are subjected to direct customer feedback. The heightened sense of responsibility also usually translates to better ownership of work. With hardened interfaces, localised issues and reduced integration efforts the net chaos in the system reduces significantly.

The parallel for SOA approach in the programming paradigm would be the Object Oriented Programming approach [OOPS]. Like OOPS, SOA is also vastly misunderstood. Most programmers fail to think Object Oriented-ly (esp the ones coming from the procedural world) and end up building poorly architected systems, while blaming OOPs for its clumsiness. Similar is the case with SOA.

We use SOA extensively in the systems we build at Althea. In my future posts I plan to provide more practical insights into SOA.

cloudsFor a Cloud Infrastructure, the ability to scale dynamically is a double edged sword.

Lets take the example of a more reactive approach to scaling on the cloud. Here, the utilization of all resources(CPU, RAM) in the infrastructure is monitored continuously and when it goes above a pre-defined threshold level, more resources are added. Let’s consider some failure scenarios that can happen with this approach.

* We know that a bot crawling the site will eat up whatever resources are thrown at it. The bot’s activity triggers the addition of more instances hence further empowering it. This leads to a sort avalanche effect and a mightily pissed off CFO.

* Adding application servers to support increasing demand while there are significant bottlenecks in the database infrastructure, further worsens the overall performance of the system.

* Spikes in traffic result in triggering off multiple instances without significantly improving the end user-experience. Hence giving rise to a bloated cloud infrastructure without sufficient business benefits.

There are many approaches you can take to plan your cloud deployment to get around these scenarios. They will be the subject of some future posts.

Procrastination

One of the most touted features of cloud infrastructures is its ability to automatically scale vertically and horizontally with almost zero impact on the running application/service. It changes the way CFOs look at IT infrastructure funding. Though the feature is paradigm shifting, it needs to be exercised with care.

In the traditional approach of hosting private infrastructures, the peak capacity is estimated and all the necessary infrastructure investments are made upfront. Inspite of this you continue to run the risk of underestimating the peak capacity. In contrast, with the cloud approach you pay only for the resources you actually use and the cloud also scales up to accommodate any overshoots.

The cloud however can make architects lazy and not design systems efficiently. Hence using up more resources than required. It may also lead to the development of systems that can respond to very high demands by adding instances, when meeting such demands may have no business benefits.