If it’s not automated, it’s not done. Changing your approach from “implement now and automate later” to “implement means automate” will take you a long way down the road to Continuous Delivery.
By Jason Mao and Rob Giseburt
The benefits of IT automation are fairly well understood – lower costs, higher reliability, and better performance. There is a popular saying in the tech world, “if you have to do something more than once, automate it.” This principle – often called DRY for Don’t Repeat Yourself – should be a core mantra for any IT organization. The key question, therefore, is not whether to automate, but when to automate.
Automate First or Pay for It Later
At Ten Mile Square, our view of automation is quite simple: Automate first. Often there will be the “task being done,” and, while completing that task, there’s the thought that “we will just automate this later.” If you know you’re going to automate already, then making automation into a separate, later step just adds to the workload and cost. Write the definition of done to include the automation. Most of the time, it will take several iterations to get the task done anyway, and the automation will not only save time later, but will also lessen the time to complete the task.
A systematic approach to replacing old technologies and applications with new can save you time and money, improve continuity of operations, and allow you to keep up with your competitors.
By Frank Oelschlager
I often work with clients that have dated technologies and infrastructures, stuff that was modern and based on (mostly) good decisions, say 10-15 years ago. Even if there has been continuous investment in revising and updating the tech (which often is not the case), it eventually reaches a point that it just needs to be replaced in order to meet the needs of the business going forward.
The reality is that we now operate technology in an ubiquitously connected environment, from employees and contractors to customers, partners, and even frenemies. Supporting this capability in a reliable and secure manner requires a modern technology infrastructure and set of capabilities that are just too complex or expensive to deliver using older technology and architectural models.
By Rob Giseburt
This is the third part of a series about using SSH with bastion hosts. You may wish to read the other parts if you haven’t already:
SSH Connection Multiplexing
If you might be opening multiple connections through the bastion host, either to a single machine or to multiple machines, it’s possible to use “connection multiplexing” to share the same connection to the bastion host as a transport to many ssh connections. This saves both resources and time establishing new connections. For a more in-depth discussion of connection multiplexing, look here.
By Rob Giseburt
A Bastion host is a special purpose computer on a network specifically designed and configured to withstand attacks. The computer generally hosts a single application, for example a proxy server, and all other services are removed or limited to reduce the threat to the computer. It is hardened in this manner primarily due to its location and purpose, which is either on the outside of the firewall or in the DMZ and usually involves access from untrusted networks or computers.