A Tinder reference on an technology company blog? That might be a first! One of our outstanding solutions architects David Peraza, will explain to you why and share his insights to approaching OpenStack solutions. We’re giving you a tease of his post here – for the complete article you can click here.
Love at first sight is great and all, but we all know you really need to get to know someone before you marry them! We think that seems obvious enough, right? You need to know what you’re getting into before you make a long term commitment.
Same goes for major purchases (are we romantics or what!). Let people try out what they are going to buy. That practice has worked since barter and trade appeared as one of the main drivers of human innovation. It worked particularly well when trade was in its infancy, when a misunderstanding could lead you to a duel for your honor, and by the way also your life. That is really taking caveat emptor seriously! Today, we don’t fight to death to resolve trade misunderstandings, for the most part, we tend to use legal systems and rule of law, which can just seem like a slow death… and of course a lot of patience. Have you been in a situation, however, where you feel you have been mugged after actually getting that online order? It does not feel, smell, and perform as described and shown in the picture. Sometimes I really feel like walking to the store to play with the toys I’m going to buy.
As ‘Agile’ development becomes all the rage, and with good reason, an old adage comes to mind; those who fail to plan are planning to fail. I’d like to share with you our experience from a recent project engagement that reinforced for us four key components necessary for a successful outcome:
Set boundaries and expectations for various roles
Attention must be paid to client’s vision and iteration deliverables
Value of commitment from the entire team
Expectations and understanding and their periodic review
Co-Authors : S. Pradhan, V. Kale, A. Varsha, A. Jadhav
Application and Virtual Machine (VM) on-boarding to infrastructure cloud platforms has become mainstream with the evolution of cloud migration tools. Creating target cloud topologies has been a major challenge during the cloud migration. A topology typically describes the network, storage and compute attributes, but network topology is the most important in the context of migration. A crucial question to be answered during cloud migration is whether we have the ability to replicate or re-create the source environment topology on the target cloud platform. Two aspects of addressing this requirement are mechanism of capturing the source network topologies and its dependencies as a blueprint, and a method to create the target cloud deployment blueprint as per the source environment at design time.
To read the entire article click here.