Secure Agile Cloud Development takes Agile and DevOps to the next level. It is about code quality, based not just on what the developers test, but also on the application of continuous testing and on dynamic and static code analysis. Most importantly, it is about a repeatable and trackable process by which we can make code quality assessments. We can find out the “who did what, when, where, how, and why” of our code. It is a useful tool in incident response. Imagine a world in which our production environments are run entirely by code.
Security focuses on end-to-end security, integrity, auditability, and regulatory compliance for virtualization and clouds, the SDDC, and the secure hybrid cloud. Security starts where the cloud and virtual environments begin: the end user computing device. (Read More)
As part of Security, we follow the user through the virtual and cloud stacks until they reach the application they wish to use for retrieving the data that is important to them. Virtualization and cloud security is implemented where there is an intersection between user, data, and application, while maintaining strict control of management interfaces. As such, we explore all aspects of security devices, tools, controls, and guides that impact or can be used to secure virtual and cloud environments.
I recently gave a Bright Talk session on adding security to the Agile Cloud/DevOps Development cycle. Part of this discussion addressed adding security testing as part of the process before, during, and even after continuous deployment. In other words, if we continually deploy, we must continually test. Our testing needs to be in the multi-minded parallel process we use for modern development, not the single-minded pipeline acceptable to most DevOps or agile processes. In the past, a team of people would test, each working independently to improve our software. We need similar capabilities within our automated processes. How do we achieve this? How do we add automated, continual testing? And where can we add this to our process or pipeline?
In a recent Twitter conversation, I asked if serverless is anything new, and if so, where are the documents expressing what is new about it. I was asked in reply if I needed a document to understand the difference between Uber and taxicabs. That got me wondering: is the serverless movement a business plan, or is it an approach to technology? If it is a business plan, then it is about how to make money; if it is an approach to technology, it is about architecture. It could also be a combination of the two. Serverless is also known as servicefull. But before we delve further, let us consider the difference between Uber and taxis.
Can you believe that we are over halfway through 2016? With summer in full swing and VMworld 2016 right around the corner, I thought it would be worthwhile to take a look at how VMware is doing and to offer some midyear insights.
Any part of any infrastructure, application, or cloud is data. Data is used by applications, and myriad data is presented to IT organizations for their use, edification, insights, and more. But what really is this data? Can we classify the types of data in some way? Data classifications should not be just “structured” and “unstructured”; they must go deeper than that. To understand how IT operations analytics (ITOA) can act on data, we first need to classify data into something we can comprehend. ITOA leads to insights that can be used to predict capacity, track applications, and tell us when we have security events.
When we talk about monitoring for performance, security, and business rules, we often refer to monitoring of infrastructure or Platform as a Service mechanisms. But how do you monitor Software as a Service? Do you just tally the dollars spent for the service, or can you look at application performance, security issues, or even your business rules today? Or do you trust the SaaS to provide data?