What is Cloud Computing?
Over the last few months I’ve been asked more and more this question: “What is Cloud Computing?” It seems the interest in cloud computing is a lot higher in 2011 when compared to last year. So, I decided to put some of my thoughts down in a series of posts and explain what I think cloud computing is all about and how you can take advantage of it. I’m very heavily involved in cloud computing and see cloud computing as the way to go despite a few hick-ups you might hear in the news.First, let me explain my background in cloud computing. I started to explore cloud computing capabilities back in 2006 when Amazon first announced their set of Amazon Web Services (AWS). Later on, companies such as Google and Microsoft followed. The first time I heard about Amazon’s Simple Storage Service (S3), I was so excited about the possibilities. I was also excited about the cost. It is extremely inexpensive to start developing powerful cloud services and solutions.
As time went by, I explored most of Amazon’s AWS services with amazement as they were updated and new ones were released. I also briefly dabbled with Microsoft’s Azure and Google’s services; but, to this day, it is my strong believe that Amazon is the clear leader in providing the best cloud services and infrastructure in the market today. In fact, I go as far as to say that Amazon is much further ahead of Microsoft and Google combined. Amazon is the clear leader if you develop on a Microsoft stack or LAMP stack. Either way, I will try to explain a little more by what I mean in the following posts.
So, what is Cloud Computing then? From an architecture point of view, I would sum up cloud computing this way:
- A cloud computing solution is partitioned logically end-to-end
- A cloud computing solution offers an infinite storage capacity
- A cloud computing solution offers an infinite computing capacity
- A cloud computing solution can handle an infinite number of users at the same time
- A cloud computing solution is always available 24/7
- A cloud computing solution is available anywhere in the world with low latency
- And yes, a cloud computing solution offers certain tasks to be completed when connections are down
- A cloud computing solution offers multiple ways to access the information such as different devices and user interfaces (platform independent on the consuming side)
- A cloud computing solution expands and contracts with resources as demand increases or decreases
- A cloud computing solution offers very fast and native execution times on the user interfaces to provide the best user experience
- A cloud computing solution offers automatic backup and recovery options for consumers
I’m coining the term “Cloud Computing Partitioning Pattern (CCPP)” and will explain next time what I mean by being able to partition a cloud computing solution in order to provide fast and successful operations from the time a request is received through a domain model all the way to persistence and back.
Until next time.
Designing Software
I have been using computers for over 24 years now. In those years, I have seen and used many operating systems and applications that run on these operating systems. I have seen software from a users point of view and software from a designers point of view when I created software solutions. In those years and up to including today, good software design seems to suffer a severe lack of attention. This results in poor quality software that is hard to use and just plain frustrating for the user. Poor software design can have serious financial impact on anyone who uses it. Poor software design makes people loose time and efficiency. Poor software design makes people wanting to cut corners or worse avoid using it all together if the opportunity allows it.I strongly believe that when designing software, the human aspect, or the end-user, the one who is actually using the software, is the center of an application. By that I mean, every software design should be centered around the user, the woman or man who will be spending a lot of time with it. Good software design is designed around a person who is using it for a particular purpose.
I wanted to express my thoughts about software design and started thinking how I can express my thoughts and ideas in a way that others can understand. I have an intense passion of creating high-quality software. Almost to a point where you can say I have an obsessive passion of creating the best software it could possibly be. But, what is high-quality software? I have come to learn that high-quality software must be coupled with greatly designed software.
Over the decades, the art of creating software has been influenced by several industries including but not limited by the construction industry, the electronics, industry, and the industrial industry. Design principles and ideas leaked from these industries into the software industry.
Designing successful software, in my opinion, can be guided by the 10 Design Principles from the Industrial design principles by Dieter Rams, an amazing industrial designer and an industry icon who has an extensive and important influence over modern industrial design. I have applied his industrial design principles to the software industry the way I see these principles can be applied. Lets first take a look at what these principles are:
- Good design should be innovative.
- Good design should make a product useful.
- Good design is aesthetic design.
- Good design will make a product understandable.
- Good design is honest.
- Good design is unobtrusive.
- Good design is long-lived.
- Good design is consistent in every detail.
- Good design is environmentally friendly.
- Good design is as little design as possible.
dVP 2009 Award
I’ve been notified that I have been selected again as a db4o Most Valued Professional (dVP) awardee for the year 2009. I’m honored and proud to receive this recognition for the second time in a row. I want to thank db4o and the db4o community. There are only 12 dVP 2009 awardee’s in the USA. Thank you.Benefits of Object Persistence
When Object Persistence is done right, there can be some great rewards in the areas of Productivity, Maintainability, and Cost Reduction. Some areas directly affect other areas. For example, if one can maintain an application fairly easily, this would result in a higher productivity. There are fine balances between these areas.Productivity
Productivity in software development can be measured in how fast a developer can complete a given work item with the assumption that the quality of the software is not compromised. How much time does it take to get things done without any compromises? Because most projects have a limited amount of time to complete, being productive impacts Cost Reduction to create and maintain the application as well as a better chance for future funding. Being productive should mean that one can get the work done and still deliver high quality software, with a high degree of reliability, and a fair amount of maintainability. Compromises in any one of these areas will result in loss of productivity either in the short-term or long-term of the product life-cycle.
The Object Persistence can be designed in such a way that the system is not locked into a particular database, for example. Because there is no database vendor lock-in, you can gain productivity by simply abstracting storage specific features. For example, if you decide to use an Object Relational Mapping Tool (ORM), you should let the ORM tool worry about creating and maintaining the database schemas for any database it supports based on your Object Model. This can buy you a tremendous amount of productivity because you are delegating this huge maintenance burden to the ORM tool.
- Productivity in software development can be gained through abstraction and automation.
Depending how Object Persistence is done, it usually allows for easier maintainability when requirements change. The fewer changes that need to be made to a system, the easier it is to maintain. Because of abstracting the object persistence, there is a high possibility that a system can be created that is easy to maintain. Because you no longer have to make changes to a database schema or data access layer, you can concentrate on making the changes usually only in one place: the object model and sometimes to the output such as the user interface or a new report
How many times have you read somebody else’s code and trying to figure out what the heck it is trying to do? Hard to read code, or Spaghetti code, is hard to maintain. In general, the fewer lines of code to maintain, the better. Because of the abstraction of the Object Persistence, much fewer lines of code are necessary. A simple method call such as the Save() method is all it’s needed. This makes the code much easier to read and to maintain.
By eliminating the database schema, eliminating a data access layer, and any data or value objects, we are eliminating several points of failures. By reducing point of failures, the system becomes immediately easier to maintain and more reliable.
The easier it is to maintain an application, the less time is required to train somebody else to learn it. Easy to understand code is easy to support no matter who will need to take over the code.
Maintainability is probably the biggest impact of an application throughout its lifetime much more so than the advantages of reusability in Object Orientation.
Cost Reduction
Studies have shown that in the lifetime of an application, 10% of the time is used to create the application, and 90% is used to maintain it until it is retired. If we can reduce the amount of time needed to maintain the application, we can reduce the amount of money spent to keep it alive. We are trying to work smarter using the right tools instead of harder using no tools or unnecessary procedures.
Being more productive has an immediate impact on cost. When a developer can implement a change quicker, the cost of maintaining an application is reduced. The time saved can be used for other duties or other projects. Many times, being more productive can allow for future projects to be approved vs. projects that won’t make the approval because the timelines would not permit to do so otherwise.
Today, labor cost is one of the most expensive liabilities a company can have. On the other hand, the workforce is also the most important asset a company has. There was a time where hardware was the most expensive part in an IT department. Hardware and tools are now extremely inexpensive today. It is mass produced and no longer a major factor in software development.
Purchasing third party component libraries can reduce the time and effort to complete an application. Some of these tools such as ORM tools can seem expensive initially, but; in the long term, you cannot afford not buying them. It is far more costly to write these components or tools on your own than to purchase them.
I’m a Mac User – I’ve done it
I’ve done it. After almost 18 years, I’ve switched from a PC to my new iMac OS X. I still can’t believe it. Over the years, I’ve always monitored Apple and how they went from a proprietary hardware system to the Intel platform with the new OS X.As a professional, I’m running my .Net development on the iMac using VMWare under a Windows XP window. Works great. The main reason to actually go out and invest into an iMac was iPhone development for the new iPhone 3G using the COCOA Touch framework and XCode.
This is really exciting and I strongly believe that the iPhone from a development point of view has a huge potential. I’ve some personal projects I’m working on for the iPhone at the moment. When the first app is released in the AppStore, I will announce it here. I’ve not felt this excited since the late 80′s when I started writing my first shareware program ACZAR.
What is Object Persistence
In the last few decades, there have
been different ways of creating software solutions from procedural
top-down development to object oriented and service oriented solutions.
They all have their place and were created based on different
requirements, budgets, and skill sets. There are always different ways
on how a software solution can be created and implemented. One way of implementing a software solution is to use Object Oriented Software Development (OOSD) and its many advantages. If
you are on a project that does not necessarily take advantage of OOSD,
that’s fine, too. Not all projects may require a full OOSD solution. In
addition, you can always refactor parts of a solution to take advantage
of OOSD techniques if time and budget permit or if new business
requirements are so that it calls for a OOSD solution.
Object Oriented Software Development is a powerful
and proven technique to create software solutions that mimic a network
of real life processes, tasks, and business rules of a domain. Most
importantly, as you design and develop your solution, you start
thinking in a domain specific language. You acquire a deeper
understanding of the business. Domain Driven Design (DDD)
is a technique within OOSD that allows you to get very intimate with the
business and requirements at hand. Eric Evans, author of Domain Driven Design, explains in great detail on how this can be accomplished. I highly recommend his book if you are interested in this exciting technique.
The premise of domain-driven design is two-fold:
* For most software projects, the primary focus should be on the domain and domain logic; and
* Complex domain designs should be based on a model.
Domain-driven design is
not a technology or a methodology. It is a way of thinking and a set of
priorities, aimed at accelerating software projects that have to deal
with complicated domains.
To accomplish that goal, teams need an extensive set of design practices, techniques and principles.
The Challenge of Complexity
Of course, many things
can put a project off course, bureaucracy, unclear objectives, lack of
resources, to name a few, but it is the approach to design that largely
determines how complex software can become. When complexity gets out of
hand, the software can no longer be understood well enough to be easily
changed or extended. By contrast, a good design can make opportunities
out of those complex features.
Some of these design
factors are technological, and a great deal of effort has gone into the
design of networks, databases, and other technical dimension of
software. Books have been written about how to solve these problems.
Developers have cultivated their skills.
Yet the most significant
complexity of many applications is not technical. It is in the domain
itself, the activity or business of the user. When this domain
complexity is not dealt with in the design, it won’t matter that the
infrastructural technology is well-conceived. A successful design must
systematically deal with this central aspect of the software.
Source: http://domaindrivendesign.org
Many books have been written about OOSD and I
encourage you to dig deeper if you are interested in learning specifics.
Besides Eric Evans’ book about Domain Driven Design and Domain Driven Design Quickly, I have also been recommending The Object Primer, by Scott Ambler. I highly recommend his Object Primer and urge you to find some time for it.
What is Object Persistence?
If you are on a project that takes advantage of
OOSD techniques, chances are that you also had to worry about storing
your domain objects at some point.
When you are dealing with a domain model, business
objects working in harmony with other business objects, you will need to
deal with Object Persistence sooner rather than later. Object
Persistence can be described as a running domain model to survive power
failures or power spikes so that no data is lost. Some describe Object
Persistence as serializing objects out to the disk and retrieving them
later. Serializing an object usually means to store the values of public
properties of an object. De-serializing would be just the opposite and
retrieve the values and reconstruct the original object back to its
original state. Others describe Object Persistence as storing objects
into a RDBMS where you will encounter the difficulties of the impedance
mismatch between the three dimensional object worlds and flat, two
dimensional relational databases equivalent of trying to fit a square
into a round hole.
In short, Object Persistence is storing the data,
the behavior, and the relationships with other objects for later reuse
to output valuable information.
A typical Object Persistence can easily consume 50%
– 60% of a project’s resources and time if not handled correctly. This
time is not just the initial time when a system is being developed. More
importantly, the future maintenance of a system is the most expensive
part of a system during its lifetime until retirement. If Object
Persistence takes up such a big part, shouldn’t Object Persistence
deserve a lot more attention?
There are several ways on how Object Persistence
can be done. I will go into some details in future posts. Until then,
think about the time and productivity that can be gained through
effective Object Persistence and not just during prototyping but full
blown production systems. How much time do you usually spend dealing
with creating a database schema, creating some layer to store “stuff”
into tables, and how much time you spend updating all these parts until
the system goes into production. Once in production, how much time do
you spend making changes as requirements change? How much plumbing work
do you do vs. actually solving the domain problems?
In future blogs, I will post about Object
Persistence and why this is so important in software development
projects that do utilize OOSD today. I will take ideas from my upcoming
book The Abundance of Object Persistence to highlight the importance of
this crucial part in system architecture not only from a technical
perspective but also from a business point of view. Please feel free to provide any comments or suggestions. I’m looking forward to your feedback.
No comments:
Post a Comment
Vulgar language in this blog is PROHIBITED....