I find it very interesting that in-house IT is seen as “the department of ‘no’” and that AWS is considered the easy place to build things. I suspect that this points to a mismatch between what an IT department thinks is important and what its internal customers think is important. I think that AWS is one of the most inflexible IT service providers I have seen. Its services are very rigidly defined. Yet, lots of businesses see AWS as a more responsive alternative to IT departments, which they see as inflexible. I think that with a change in focus, internal IT departments can become far better at providing what the application teams require.
Transformation & Agility
Transformation & Agility concerns the utilization of the technical agility derived from the benefits delivered by virtualization and cloud computing, coupled with Agile Development practices that improve business agility, performance, and results. This includes the agility derived from: (Read More)
- The implementation of Agile and DevOps methodologies
- The application and system architectures
- The implementation of IaaS, PaaS, and SaaS clouds
- Monitoring of the environment, coupled with processes for resolving problems quickly
- Having continuous availability through the use of high-availability and disaster recovery products and procedures
Transformation covers the journey from A to Z and all points between: how you get there and the roads you will travel; how decisions made on day zero or one, or even day three, will affect later decisions; and what technical, operational, and organizational pitfalls can be associated with an implementation. We examine what tool sets are required for Agile Cloud Development, and it delves into other aspects of Agile Development that integrate with cloud computing, SaaS, and PaaS environments, including DevOps, Scrum, XP, and Kanban.
We are currently midway through an information and digitization revolution that could be possibly compared to the mechanical impact of the Industrial Revolution. Despite the many great advances it brought, the Industrial Revolution had harmful impacts on the environment and working conditions, among other areas. It took 150 years or more for the issues from the Industrial Revolution to be recognized and addressed with legislation, by which time untold damage had been done. Similar things are possible with the current “information revolution.” The big issues of today are concerns over privacy and data protection. Given that Europe has a history of personal information being used to enforce totalitarianism and even genocide, it is no surprise to find that Europe is on the forefront of making data protection legislation more suitable to the age we currently live and work in.
Software-defined storage (SDS) within the container realm often ignores storage itself. In essence, the SDS platform assumes some chunk of storage is mapped to a container host. Then, it takes over from there. SDS for containers is the orchestration through which persistent storage is mapped to a container. This gives it a unique ability to provide a mount point the SDS layer can control. It also provides a unique view of the world. SDS for containers bypasses traditional storage yet provides for retention, replication, and erasure coding. These are just some of the features, but it does not care what storage is underneath the container host. This assumption could lead to issues down the road, but how does this work?
Recently I attended DockerCon in Austin, Texas. Docker has been gaining an increased amount of interest in the enterprise for both building new greenfield applications and migrating legacy applications. Docker has become synonymous with microservices-based architectures, but enterprises are mired in legacy applications. In my experience, well over 90% of all workloads in enterprises are not microservices-based architectures, so I was interested in hearing how Docker would address this issue.
As I turned yet another year older, I began to wonder about my career. Where it has taken me? What have been the pitfalls and pratfalls? Then came the realization that DevOps is not the end game. It is not even the beginning. It really just a part of the journey: a part that seems to have taken a left turn to nowhere but at the same time to everywhere. So, what does it require to deal with today’s IT? Does it take DevOps? I think not. Does it take a new mindset? Perhaps. Does it take new skills? Maybe. Embracing the new over the old? Not really. So, what does it take?
DockerCon 2017 was about modernizing traditional applications, or MTA. MTA is the lifting and shifting of traditional Microsoft Windows base applications into Docker containers. Its approach is reminiscent of 2009. For Docker to grow into brownfield data centers, this is a must. However, could it be doing more? If so, what is it doing that could be improved? MTA is a must for many organizations looking to Docker to manage everything, but not everything uses the same approach. Containers are about agility, with workloads being treated like cattle. Can traditional applications be treated this way? We shall see.