Last post on this blog, starting my own at http://rajith.2rlabs.com/

I had some web space available for over an year and decided to use that space to run my own blog at http://rajith.2rlabs.com/.

I have imported all my previous posts into my new blog. I found Word Press easy to work with yet flexible and powerful enough to customize the way I want. I am using blueprint as my theme and found it to be very elegant. It's built on the Blueprint CSS framework. If anybody is interested you can download it from here.

Many thanks to the Blogger team for improving blogger over the last few months and I thorughly enjoyed my blogging experiance here. I like to be in control of my everyday life, including blogging. Hence my move to my own thing.

Scaling your system - What I learnt from Dan Pritchett's (eBay) talk

I was lucky enough to attend both talks given by Dan Pritchett during the Colorado Software Summit this year. The first one was, "You Scaled your what". If you want to know what scalability is, here is an excellent introduction by Werner Vogels. After listening to what Dan had to say, the following points stood out in my mind

• You need to understand and take complete control of your architecture. Read my post on Architecture is your responsibility for more thoughts on this.


• You need to have scalability in mind right from the beginning. Trying to achieve scalability later can be time consuming and very costly. Quoting from Werner Vogels post

Why is scalability so hard? Because scalability cannot be an after-thought. It requires applications and platforms to be designed with scaling in mind, such that adding resources actually results in improving the performance or that if redundancy is introduced the system performance is not adversely affected. Many algorithms that perform reasonably well under low load and small datasets can explode in cost if either requests rates increase, the dataset grows or the number of nodes in the distributed system increases.


• Transactional scaling is just one dimension. You need to think about Scalability of data, operational,deployment, power ..etc. This is a minimalistic set. Try to figure out what dimensions are important to your organization.


• All scalability dimensions are related and impacts each other. Any dimension ignored can could evolve into a problem for your application


• Prefer vertical over horizontal scaling. Vertical scaling is better for your vendors and is not a viable long term strategy. There is so much you can get by increasing memory, CPU etc..

Transactional Scaling
Usually measured in TPS and is a traditional indicator for application performance.

• Keep asking the question "How long can the business survive?" based on,
  
  
  
  • Time-to-live on current resources.
  
  
  • Time-to-live on maximum plausible configuration.


• These metrics should be taken regularly to anticipate possible production bottle necks and identify issues before they become a crisis.

Data Scaling
How well does your data scale? Think about,

• Functional Decomposition, group data by logical relationships, business importance,transactional volumes etc.


• Think about partitioning data (sharding).


• Is all data equally important? prioritizing your data and allocating resources accordingly will help you scale better.

Operational Scalability
How hard is it to run your software? Operational scalability is a software problem and you need to think about operational concerns right from the beginning. Pay attention to,

• Logging metrics, Monitoring.


• Controlling/updating/tuning live apps without disrupting traffic.

Deployment Scalability
You need to design/architect your systems while keeping the following in mind,

• Ability to do incremental roll outs (and rollback if there are problems) without disrupting live traffic.


• Managing component dependencies during deployment without disrupting live traffic.


• Your architecture shouldn't assume or decouple itself to any hardware,network topology or data center topology. This allows you to take advantage of new hardware, network topologies ..etc without significant changes.

Power Scalability
Power can be a limiting factor in a data center and may put bounds on transactional scaling.

• How efficient is your software?, wasted clock cycles == wasted watts.


• Consider vitalization for best utilization of your hardware resources.
  

Some good tips I managed to note down

• Run old and new schema parallelly and then take out the old schema after a while when you gain enough confidence.


• Prioritize services, willing to take a hit on certain services over others.


• Incremental rollouts is a very good way to roll out new features while managing risk and also prevents taking the system offline.


• Schedule deployment during working hours instead of weekends/nights as this enables your developers, support staff to attend to problems while they are alert and without being distracted by non work issues.If you do incremental rollouts this is possible as you are not disrupting traffic.

The value of principled design - REST is just one example

To me the value of Roy Fielding's dissertation goes beyond REST. Steve Vinoksi summarised it very well in one of his comments while answering a comment I made on his blog.

It’s(Roy's dissertation) not really primarily about REST; rather, it’s about principled design. Much of his dissertation is about architectural elements, principles, constraints, properties, and the relationships between them all. REST is used as a very clear example in chapter 5 of what principled design is all about.

Why can't we use a principled design approach when we do SOA or for that matter any other architecture?

When we add contraints or relax constraints we induce certain properties in our architecture. As an architect you make an educated desision as to what constraints make sense in your environment and what doesn't. When designing systems don't we go through decisions like "should we make these services stateless or statefull ..etc" during our design meetings ?

I think in what ever system you design as an architect you should think through and note down the constraints you want to impose on your system. This will provide a proper foundation to your system and an excellent guideline to your developers which will clearly communicate the desired goals of your system. Then later on when somebody else wants to relax any of these constraints or add more constraints they already have a guideline and can see how the "relaxing of an existing constraint" or the "addition of a new constraint" can impact the overall system.

REST is just a name coined by Roy to identify a set of constraints, and they are not the only constraints, nor the best combination of constraints in every situation. As Steve mentioned Roy spends the first few chapters providing an excellent analysis about "architectural elements, principles, constraints, properties, and the relationships between them all" and of course the value of a principled design approach.
To me the value of Roy's thesis goes beyond REST and I hope most people would realize the same.

Global Warming ...is it really?

Dwight Hornbecker, the only geologist I've even known, had some very interesting facts about global warming. They sound kinda crazy, but I wonder if they are true. Here is what he told.

• One volcanic eruption can contribute to global warming more than what humans can do in an year
• The earth was actually warmer than what it is now.

Dwight went onto explain that there is evidence to support that, a few million years ago the earth was a lot more warmer than what it is today. Then came the ice age. And he maintains that we are still recovering from the ice age and earth is slowly returning back to it what it was. Not sure whom to believe. Is it Al Gore and his crew or Dwight?

All I know is that humans haven't really figured it out yet. We think we do and try to mess around with nature, but I don't think we are even close at guessing/figuring out the real situation.