As I read the “we solve ransomware” emails in my inbox and saw comments on Twitter and Slack, I started to think about how to solve ransomware once and for all. It sounds like a difficult task, but I think it is all about an architecture: an architecture that uses modern ideas. A solution needs to combine security with data protection. I have written about detecting ransomware before, but now we need to find a way to include everything we know to ensure institutions can recover quickly from a new attack while preventing known attacks. This concept came to fruition at VeeamON 2017, and I briefly spoke about it on The Cube. Now it is time to put everything together.
Articles Tagged with Architecture
The title of this article is “In the Hybrid Cloud, Your Role Matters, but…,” and there is a big “but” there. How you use your role is what really matters. Whether you are a cloud, virtualization, or container administrator, evangelist, or architect, how you use your role makes or breaks the secure hybrid cloud. We have written a lot about technology, but it’s the people who really make the technology a win for the business. It is the processes you develop that make the difference. It is the roles you entrench that can hurt your prospects. So, how do we eliminate the “but”?
I’m going to diverge ever so briefly from my “Reversed Assumptions” posts to share some happenings in this current engagement I’m on and to tie in some of the previous posts on design and architecture. This post focuses on what architecture is and what it isn’t. As I have engaged with many different sizes of customers over the years, one thing remains true: architects and architecture are many things to many people. There has been a lot of talk and debate on this, and I thought it necessary to be sure about what architecture truly is, and who is qualified to practice it.
One of the things I find very peculiar is the tendency of companies to hide their documentation. Sometimes the documentation is available only to existing customers, behind a login on the support site. At other times, the only documentation is the online help. Often the only things available to prospective customers are a few shiny marketing documents and maybe an equally shiny case study. At the same time, we hear that 67% of the buying process happens before talking to salespeople. Personally, I find that the technical implementation guide gives me a better understanding of a product than a lot of marketing slides. I also like to read a few support documents to get an idea of what issues I might face if I deploy a product.
When I was a small child, I used to enjoy watching a Japanese language program. Called Monkey, it was all about a disruptive monkey with a massive ego. The monkey was turned into immortal being that could shrink and grow and travel on a flying cloud. Punished by the heavens for its transgressions, it was traveling with a Buddhist monk called Tripitaka on a journey to recover holy scriptures. The program also included a water monster, a pig, and a dragon who was shaped like a horse. It was a thing of its time, and you need to have watched to understand. By now, you most likely think that I have finally snapped, but this rather oblique journey somehow got me thinking about IT architecture and the ability to scale.
I wrote a couple of articles many years back about building an agile and flexible enterprise using a set of models, principles, and design rules that address the need to maximize financial return, improve performance, minimize risk, and enhance business agility. I want to revisit the premise of that article and view it through the lens of DevOps.