After more than five years of DevOps, definitions are evolving, boundaries are expanding, ‘unicorns’ are no longer rare, enterprises are on board, and pundits are moving on. Can we now look at an evolution of DevOps? Should we? Is the foundation of DevOps ‘done’, or is there still too much left to do? What is mature, and what is still missing? What does the next 5 years of DevOps look like? In this Power Panel at DevOps Summit, moderated by DevOps Summit Conference Chair Andi Mann, panelists looked back at what DevOps has become, and forward at what it might create next.

read more

The computing world just keeps on progressing but as we all know with progress comes additional challenges. This is especially true of challenges around security. Every advance in computing has given rise to the same question: “how do we secure this new toy?”

When client/server architecture was all the rage in the late 1990s there was great excitement about the advantages it brought about but also a concern for the security implications of distributed clients and centralised servers. When server consolidation came of age in the early 2000s the concern was how to keep applications secure when running on the same server.

In the age of cloud computing, we seem to have introduced more security impacts than ever before. Cloud computing has been the basis for many tremendous benefits in the computing industry and has positively impacted many businesses around the world. While we can celebrate all the advances we need to be very aware of all the new threats that have come with the steps forward. The following are some of the areas that concern security professionals in the 2017:

Cloud

As I have stated in a past article, security concerns are still the number one impediment to cloud adoption in the computing world today. With that said, more and more organisations are moving production workloads to the cloud every day and how to secure those workloads is a question with no single answer. Whether cloud workloads are treated as if they are in one’s own data center or secured through as-a-service tools, placing workloads into the cloud comes with some measure of uncertainty that requires research, planning, and execution to mitigate.

Edge/fog networks

The concept behind fog computing isn’t really all that new. I remember moving web servers to the outer edge of the network, outside the firewall, so that they can be closer to the users. The difference now is that fog computing supports larger numbers of devices either at the edge of the managed network or, in the case of IoT, placed physically very far from the control plane.

The somewhat obvious threat vector is the vulnerability of these fog/edge to attack and the continuation of that attack to the control plane, aggregation layer or even all the way to the virtual private network or data centre. This needs to be dealt with in much the same way as this type of problem was handled in past. The fog/edge devices need to be hardened and the communications path between those devices and the aggregation layer and the data center (cloud or other) need to be secured.

Mobile users

It was so much easier to secure an environment when we knew who our user base was. Well, not anymore. The preponderance of mobile devices that the service developers can have no control over, leaves the service network open to attack via those devices. A user who utilizes your provided tested and secured app could easily have installed another app which is just a front for malware of some kind. Beyond just writing apps that are secure the systems as the front end of the data centre or cloud environment that support these apps have to be strongly secured. Additionally, communications between app and service layer need to be secured and monitored.   

Malware

On June 26 the largest container shipping company in the world Maersk Lines, Russian oil producer Rosneft, and pharmaceutical giant Merck, along with hundreds of other institutions around the world, were all but shut down by a global malware/ransomware attack.

That the perpetrators used various public cloud-based resources to launch the attack is a very real possibility. Security professionals around the globe are concerned about the form the next big malware, virus, or ransomware attack will take. Practical and logical steps, including planning for recovery, training, and maintenance, need to be taken to prevent organizations from falling prey to these attacks.

Global data expansion

Many years ago, I wrote an article on how server consolidation can positively impact data centre security by reducing the number of operating system instance to maintain and by reducing the number of possible targets for hackers. In today’s ever expanding global data environment we have to ask ourselves: have we provided too many targets for the bad guys?

The answer is maybe. Each individual and organisation have to be engaged in preventing data loss and data theft by utilising the many means of securing data that exist today. Data at rest encryption, automated and versioned replication or version backup, are just some of the ways an enterprise can protect themselves. These security concepts apply equally to preventing and/or recovering from malware attacks.

The only way to survive the many security threats that exist is to: recognise the threats, learn about them and how to fight them; build a comprehensive plan for protecting your organisation and for reaction to and recovery from an attack; whether it is basic security maintenance or implementation of major security efforts, take action. Don’t just sit back and wait for an attack to happen.

The public cloud computing sector is in a constant state of evolution, as vendors design new IT infrastructure architectures and service providers deploy them in their own unique hyperscale data centre facilities.

According to the latest analysis of cloud pricing by 451 Research, for the majority of new applications, a serverless solution offers a lower total cost of ownership (TCO) than both virtual machines (VMs) or containers.

Severless cloud market development

When analyzing serverless offerings from the leading public cloud service providers, 451 Research determined that IBM generally offers the least expensive service, with Microsoft leading for certain other configurations.

According to the 451 Research assessment, the TCO of serverless tends to be lower than VMs, even when the VM is hosting containers, because there is no need for developers to provision, configure and manage the infrastructure.

As an example, when a serverless function is active for just three quarters of the month, it only takes a 10-minute saving in operational overhead for serverless to beat virtual machines on TCO.

451 Research analysts believe that even without the savings in developer time, the ability of serverless to increase utilisation means it is cheaper than using VMs when the code is executed fewer than 500,000 times each month.

451 Research finds that IBM is least expensive for 0.1 second duration scripts, and Azure is cheapest for 10-second scripts – assuming memory requirements match predetermined size allocations.

Besides, IBM offers a distinct cost advantage by allowing users to choose exact memory requirements, whereas other cloud service providers round up the figures, resulting in users typically paying for unused capacity.

That being said, and considering the similarities in pricing methods and offerings between cloud service providers, 451 Research believes serverless is poised to undergo a round of price cutting this year.

“Serverless is more than just hype; it has the potential to transform the way we develop, build and run applications in the cloud. Understanding the economics of serverless technology is vital to understanding its potential to disrupt the industry,” said Owen Rogers, research director at 451 Research.

Outlook for serverless cloud services

Freemium serverless offerings are already fueling the growth of new services by stimulating experimentation and helping enterprises gain skills. In the analyst’s opinion, this could result in serverless solutions becoming the next cloud ‘price war’ battleground.

451 Research expects adoption of serverless – or FaaS (functions as a service) – to continue growing over the next few years. In its 2016 market study, 37 percent of the IT decision-makers surveyed were already using serverless technology.

The term ‘serverless’ implies that no servers are used to run an application or service. But in reality, this model means that developers and cloud service providers do not encounter the typical complexity and maintenance management of VMs or containers.

Cloud Expo, Inc. has announced today that Andi Mann and Aruna Ravichandran have been named Co-Chairs of @DevOpsSummit at Cloud Expo Silicon Valley which will take place Oct. 31-Nov. 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. “DevOps is at the intersection of technology and business-optimizing tools, organizations and processes to bring measurable improvements in productivity and profitability,” said Aruna Ravichandran, vice president, DevOps product and solutions marketing, CA Technologies. “It’s this results-driven combination of technology and business that makes me so passionate about DevOps and its future in the industry. I am truly honored to take on this co-chair role, and look forward to working with the DevOps Summit team at Cloud Expo and attendees to advance DevOps.”

read more

Human body is the most complex machine ever created! With a complex network of interconnected organs, millions of cells and the most advanced processor, human body is the most automated system in this planet. In this article, we will draw comparisons between working of a human body to that of a data center. We will draw parallels between human body automation to data center automation and explain different levels of automation we need to drive in data centers. This article is divided into 4 parts covering each of body main functions and drawing parallels on automation. This is 3rd article in the human body series, please go to http://ashishnanjiani.ulitzer.com or http://ashishnanjiani.com

read more

Public cloud services will be the fastest growing market segment for IT deployment in 2017, according to the latest note from IDC.

Spending on traditional data centres, which ranked at more than 60% of the market in 2016, will dip to less than half by 2021, the analyst firm argues, with public cloud taking the majority of the slack.

Total spending on IT infrastructure for deployment in cloud environments – server, enterprise storage and Ethernet switches – will reach $40 billion (£31.1bn) in 2017, at an increase of 12.4% year over year. Public cloud will grow at the fastest rate, of 13.8%, with off-premises private cloud environments at 11.9% growth and on-prem private clouds growing 9.6% year on year.

iCharts

For cloud IT environments, Ethernet switches will represent the fastest growing segment, with 25.8% year on year growth in 2017, with spending on enterprise storage at 12.0% and servers 9.1%.

IDC had previously examined the numbers by vendor, finding Dell and HPE just ahead of the faster-growing Cisco, and saying global cloud IT infrastructure revenues hitting $8 billion in the first quarter of 2017.

Natalya Yezhkova, IDC enterprise storage research director, said spending will continue on 2016 trends in general, not counting differences in specific technology segments.

“Enterprise adoption of hybrid and multi-cloud IT strategies and the proliferation of cloud-native applications and areas such as the Internet of Things, which embrace a cloud-first approach to supporting IT resources, will fuel further increases in end-user spending on services-based IT.

“In turn, this move will be reflected in a shift of the overall spending on IT infrastructure from on-premises to off-premises deployments and from traditional IT to cloud IT,” Yezhkova added.

One of the worst data breaches in US history recently made the headlines, and it’s a powerful reminder of the importance of protecting data on platforms such as Amazon Web Services (AWS).

The personal details of nearly four out of every five adult Americans, including virtually every registered voter, were recently exposed online thanks to sloppy security practices. The data not only included contact details and birth dates, but also information on the perceived political views of individuals. Media analytics company Deep Root Analytics had stored the data in an AWS S3 bucket and mistakenly left it exposed for two weeks.

Deep Root Analytics failed to use protected access settings, meaning that the data was accessible to anyone who knew, found, or guessed the six-character subdomain name that Amazon uses to identify an individual bucket.

While in this case it was a very simple user error that was to blame, it’s also a reminder of the wider risks of IaaS platforms such as AWS. Amazon has put a great deal of time and money into AWS’s security, but it’s always possible that either a security misconfiguration by an AWS customer or a particularly powerful attack could create a breach.

Organizations that use AWS also need to take into account the risk of malicious or mistaken activity from their own staff and users along with third parties such as business partners or vendors that require some degree of access to data. The average business faces around 11 threats every month where somebody inside the organization is responsible, whether deliberately trying to compromise security or acting negligently. Meanwhile, third parties with access to data are often to blame for security breaches.

Simply leaving AWS security up to Amazon is neither legally or practically sensible. That’s because AWS uses a shared responsibility system when it comes to security. Amazon itself takes full responsibility for the protection of its cloud systems, including both the software set-up and the physical computers, servers and connections. It’s also in charge of detecting and blocking any intrusions or fraudulent attempts to gain access.

However, the customer is responsible for managing and configuring everything that happens inside AWS. This includes any applications it runs using AWS’s identity and access management system (IAM), along with password protection of the data. The customer organisation is also responsible for protecting its own systems and connections to AWS, including any firewall.

How to use AWS infrastructure safely

This isn’t an all-encompassing list, but it covers the main points and lays a good groundwork for a sensible and effective approach.

Enable CloudTrail everywhere you use AWS: This creates comprehensive logs of all user activities in an AWS service and provides an audit trail for compliance purposes. Remember to do this on all services, including non-geographic services such as CloudFront. You should also switch on multi-region logging as this will pick up any activity in regions you don’t use, a strong sign of a security breach.

Enable multifactor authentication (MFA) on your root user account: This is absolutely key as this account can access all your AWS resources. Use a dedicated device for this MFA rather than have the requests sent to a personal mobile device. That cuts the chances that a lost device or a change in personnel can lead to a breach.

Enforce a strict strong password policy: A good minimum threshold is 14 characters with at least one uppercase letter, one lowercase letter, one number and one symbol. Set passwords to expire after no more than 90 days and don’t let staff reuse passwords.

Keep CloudTrail log access as tight and narrow as possible: This will reduce the number of staff who could compromise security by falling prey to a phishing attack or being blackmailed.

Make sure multifactor authentication is required to delete CloudTrail buckets: This will reduce the chances of a hacker covering their tracks after getting unauthorized access.

Never use access keys on root accounts: Doing so is simply too big a risk given how much access somebody could gain after compromising an account.

Restrict access for commonly used ports: These can include CIFS, DNS, FTP, MongoDB, MSSQL and SMTP.

Set accounts to automatically expire after 90 days without any use: An inactive account brings you no benefits but increases the number of potential points of entry for somebody trying to breach your setup.

Turn on access logging for your S3 buckets: This compiles the log data from CloudTrail and makes it much easier to track access requests, authorized and otherwise. If the worst happens, these logs can help with breach investigations.

Use restricted access on any EC2 security groups: This cuts out less sophisticated attack tactics such as Denial of Service, man-in-the-middle or brute force. Make sure access is done via IAM roles rather than through individual credentials that can easily be compromised.

As well as taking care of the restrictions and policies of your AWS infrastructure, you should also follow best practice when you use any custom applications deployed in AWS. By following these best practices, enterprises and users alike can safely store their data in the cloud without compromising security, creating a more secure AWS environment.

Read more: Report argues ‘concerning’ lack of understanding over IaaS shared responsibility models