Kevin, How did you get fit? - 10 Steps for Anyone

I'm 56 years old, and I am as fit, healthy and happy as I have ever been. 

Kevin Eb, September 2024, Hull, MA

As a young person, I was somewhat active, but not particularly athletic. And like other young people, I could eat whatever I wanted, and not gain weight. Of course, that changed as I slid into my 30s. For my 30's and 40's I was borderline obese. I'm 5' 8" At my heaviest I tipped the scales at 200 pounds. 

In the last few years I have shed forty pounds. A long with losing the weight, I have gotten fit. I bike, swim and run. At first, I was only riding my bike, but building up my strength. After a while I incorporated swimming and running. When I began incorporating running into my fitness routine, I could barely run. I would run on a track near my house. I'd go down the 100 meters of the straight-away and then I couldn't run anymore. I needed to stop because of the pain in my ankles or shins. Now, a 5k run is in my comfort zone. My longest run is a half-marathon. I can bike forty miles comfortably. I love open water swims (and surfing!). I have participated in two sprint triathlons. I am as fit, healthy and happy as I have ever been. 

This change has not gone unnoticed by friends and family, who have been wonderfully supportive and enthusiastic about my progress. I get asked, "How did you get fit?" After enough people have asked me this question, I thought it would be helpful to share what I've learned. Here's my response. 

The number one thing I would say is, lower your expectations. Don't try to get fit. Getting fit will be a long journey. Focus on getting healthier. If getting healthy is your focus, there a lot of things you can readily do, and a number of them have immediate benefits. You probably know most of them already. The challenge is to put them into action and to keep up the effort. Here are my ten steps to a healthier and happy life. 

1. Begin

I mean that literally. Just get started. Don't be so impressed by the challenge, that you don't get started. The only way to make progress is to begin. Don't even think about it as "day one." Think of the right now. Make right now the moment you set an intention to improve your health. 

2. Get moving

Even a moderate amount of physical exercise, a brisk 20 to 30 minute walk five days a week, will make you healthier. Our bodies are built for moving. Our bodies are also very efficient at storing energy and avoiding any effort at all. Like most of the steps in this list, the science is clear, a moderate amount of regular exercise (walking!) has measurable health benefits. Get moving!

3. Push past your fear

Getting healthy can be daunting. It gets harder, as we get older. We bear the emotional scars of diet failures, and abandoned exercise plans. Fear of injury is real. We step gingerly in fear of twisting an ankle. As we get older, we are more aware of the frailty of our bodies, and get yet more cautious. Push past your fear! You will experience discomfort. Don't let discomfort be your master. You can take it. You're stronger than you know. Injury and pain can happen whether or not you make any effort to exercise. 

Don't be afraid. You have the power! You can do this! 

4. Listen to your body

Our minds are built to focus our attention on one thing at a time. This is necessary in order for our executive function to work. We need to ignore all kinds of information from our bodies and our surroundings, so we can focus on whatever needs our active conscience attention. Your body is the temple of the mind. It's where you live. Give your body the attention and respect it deserves. 

5. Improve your posture -- This is the start of your fitness plan

You deserve to be here! Whatever state your body is, hold your head up high. Sit straight, and walk with your head up. Your posture will bolster your sense of well-being. There are different ways to improve your posture, and begin to put together a fitness plan that meets your needs. Start your fitness plan with exercise that is low impact. You don't need equipment or props. Your breath animates your body and your mind. Be mindful of your breathing. Your intention is to develop a fitness program that is more than doing push-ups, or leg stretches or any other activity that focuses on a particular muscle group. What you want to do is to begin a fitness program that integrates your mind, body and breath. Yoga is an excellent way to do this. I'm saying "yoga," but it doesn't have to be yoga. Yoga is an excellent way to do this. You can start wherever you are at--including chair yoga. Pilates is also good. Whatever exercise you choose to do, aim for a full-body experience: mind, body and breath. 

6. Track what you eat. Eat food. Mostly plants. Not too much.

Tracking what you eat, is not dieting. It is being mindful of what you are putting into your body. Whatever you eat, record it. The only goal you should set for yourself, is to actually record what you eat. If you maintain diligence in recording what you eat, you will inevitably begin to make better decisions about what you decide to put into your mouth. Hat tip to Michael Pollan for, "Eat food. Mostly plants. Not too much."

7. Weigh yourself daily

Weigh yourself daily, but don't pay too much attention to how much you weigh on any particular day. Body weight can fluctuate significantly. Our bodies can store a lot of water. Water is heavy. It is not uncommon to gain or lose five pounds in a day. Even without a big body weight swing of five pounds, body weight fluctuates. A more accurate measure of your weight is probably some kind of running average over your last few days. So, don't much attention to how much you weigh on any particular day. But, do record your weight everyday. Make it part of your daily routine. Weigh yourself, even when you don't want to know what you weigh. It's really an exercise of personal accountability and mindfulness. It's not difficult to step on a scale. It is difficult to make yourself regularly accountable and take stock of where you're at. 

8. Sleep

Of all the things on this list, sleep is arguably the most important. There's really no more important thing we can do for our mental health, and concurrently, our physical health, then consistently sleeping well. This is science. If you are not sleeping well, see a doctor. Fix that shit. It's a bit ironic, that sleep, "doing nothing," plays such a big role in our physical health. But it does. 

9. Rest, Recover, Strengthen

As you get into a more active exercise routine, rest and recovery will be grow in importance. I do think "rest and recover" doesn't really speak to what's happening. Yes, your body is "recovering" after exercise. Inflammation is processed by your body and soreness recedes. But, the sometimes neglected point of recovery, is that is necessary to actual grow muscle. You can't grow muscle while you are using your muscles. They need to rest in order to strength. Kicking your ass with your exercise routine? Rest, Recover, Strengthen. 

10. No matter what happens, be kind to yourself

You are going to have bad days. You will have days when you miss all of your goals. Days when you eat too much and don't exercise. Don't beat yourself up about that! Just don't. You only live once. If you indulged, that's okay. Gloat over your indulgence, and move on. It doesn't really matter what you did yesterday. What matters is what you decide to do next. In order to be more healthy, you have to set your intention to be more healthy everyday. That's a challenge, but it is also a blessing. Everyday we have the opportunity to start over. Everyday we have the opportunity to make new decisions and head in different directions. It's miraculous that we are here at all. Every step we take is a blessing. Be grateful for the health and wellness you have. Be kind to yourself. You deserve it. 

Please share any of your comments and experiences below!

Service and a Culture of Ownership for Information Security

Ownership

No time for losers, cause we are the champions of the world!

DevOps practitioners take ownership not only of their individual performance, but also in the success of the team, and recognize that work they do has an impact on the success of the whole company.

Persistence

After I graduated from college, I backpacked around the world. I visited great cities: Hong Kong, Bangkok, Singapore, Beijing, Delhi, Mumbai, Jerusalem, Cairo, Marrakech. I trekked and climbed; I did odd jobs and taught ESL; I met incredible people and learned so much. I was out of the country for more than a year. That was 1995, the "Year of the Internet."  The Internet was exploding back home, and I could feel it. When I returned to the States, I was ready to launch my career. I moved to the Bay Area and started looking for a job.  

I had my old Apple Macintosh. I busily played with Java and HTML making wildly homebrew web pages; linking my page to people that I admired and making graphic puzzles linking to all manner of strange and interesting things. I followed job postings on Craigslist, when it was still a listserv. These were dial-up days and I networked online bulletin boards, like The Well. In a Java conference, I connected to one long-timer user, Bob Pasker, aka (rbp). Bob arranged a phone call to talk about a Systems Administrator position he had at a startup he co-founded, WebLogic. 

Or dumb luck?

It's worth stepping out of this story to make note that when it came to technology, nothing got by Bob. There was no obfuscating or charming your way past him. You knew if you were not doing well in an interview with him. One person that did get a job at WebLogic that had a particularly memorable reaction to his interview with Bob. Michael Smith, Jr, Smitty, who was interviewing for an entry level Sales Engineer position, started the interviewing feeling pretty good, and left feeling like he knew nothing about Java. 

Back to my interview. None of my experience and education--Electrical Engineering, AS/400, retail software, Novell 4.0 certification nor the Java basics I was teaching myself was of much use in this interview. Nevertheless, I was confident and insisted I could learn. I doubt I was convincing, but as Bob was extricating himself off the phone, he did offer me a temp job setting up some computers. I said yes.  

WebLogic, early days

Soon after I showed up in WebLogic’s downtown San Francisco office. The WebLogic office was tiny. They shared space with an accountant. The accountant had a corner office and a couple of adjoining rooms. Four smaller offices comprised the rest of WebLogic’s space. Dave Parker, the WebLogic president, occupied one of them. There was a small conference room with a floor to ceiling glass wall. That conference room sticks my mind. Dave gave what seemed like an inordinately long interview to a very attractive young women who wore her red mini-skirt very well. It turns out, that Dave was capable of talking an inordinately long time for any occasion at all. But, I digress. In another room Bob was setting up for the first three staff engineers they hired. One was for Sam Pullara and another was for our departed friend Joe Weinstein. The four co-founders, Bob, his wife Laurie Pitman, Paul Ambrose, and Karl Resnicoff worked from home over an ISDN network Bob setup. 

Bob had three mini-tower workstations to setup for his new engineers. The workstations had arrived from Micron along with some 3^rd party memory upgrades. Bob handed me the memory, and told to get to work installing it. This was something I'd already done a number of times in my life. I knew exactly what to do. And yet, I was so nervous I could hardly hold the memory stick. I could not get it to pop into the socket. After a bit, Bob quietly lost his patience watching me fumble with the memory stick. He reached over and popped it in. And we moved on.

I left some kind of impression on him, because I heard from him soon. Bob had me back to setup more computers. I setup Windows NT 4.0, Microsoft Office and development tools, like Perforce and Cygwin. Soon WebLogic was prepping to move out of its shared office and into larger space. Bob needed someone on the IT front-line to help get things going, and offered me a full-time job. At the same time, I was offered a more money to be a Novell administration for a San Francisco hospital. I passed on the Novell job and went to work at WebLogic.

First Days at the Job and Lessons Learned -- WebLogic 1996

בּוֹקֶר טוֹב

On my way to my first full-time day at WebLogic, I emerged from the BART station at Montgomery St. A a well-dressed stranger greeted me with Boker tov! Good morning in Hebrew. I had arrived at my destination. I headed underneath the Charles Schwab ticker; looked up at the sun shining on the pyramid building; and marched down Montgomery St. to start my new job.

One day during my first week, I was asked to move a printer. There was some issue, and it was taking me time to get it working. This did not go over well with Bob. He made it clear to me in a way that has stayed with me always: IT is a service job. Yes it’s technical, but its function is to enable other people to get their work done. Printers and cables or anything else technical did not come up in this discussion. The point was about providing service to business users. If my work is causing a work stoppage because the printer I am working on is off-line, I am not getting my job done. I took that feedback, and remembered a theater “techie” creed: 

You don’t see or hear us, but you don’t see or hear without us!

 

Fourk 3: IT is a service job. Yes, it’s technical, but its function is to enable other people. 

Service and a Culture of Ownership for Information Security

It's 2024 now, nearly thirty years later, and this is a lesson I come back to often. It is lesson that I routinely share with my Information Security colleagues. As Information Security practitioners, our function is "Information Security." Our purpose is Risk Management. We support the business by safeguarding its assets and ensuring compliance. We do this in order to reduce risk to the business. Understanding and embracing one's mission is a the first requirement of the, National Institute of Standards and Technology, Cybersecurity Framework (NIST CSF v2.0 released in March), which states, "The organizational mission is understood and informs cybersecurity risk management." By maintaining a service-oriented approach and aligning with our mission, we not only secure the company but also ensure we meet compliance objectives and foster an Information Security centric culture of ownership. 

Security DON'T dos, The Wild West of Old and DevOps to the Rescue

Security Tenets

Keep these DON’Ts at the top of your list.

 

Fourk 7: Security DON'T dos

1. DON’T leak data.
2. DON’T corrupt data. 
3. DON’T keep users from their data.

DO keep your customers data secure. 

 

Kevin Eberman's take on the triad, the three legged stool of Information Security: 

confidentiality, integrity and availability

The tenets of Information Security deserve regular consideration. They form the basis of many laws, regulations and industry standards. When I was first introduced to this formal definition of security tenets, I learned Information Security is about more than keeping secrets. I was expecting confidentiality to be a concern, but I did not expect integrity and availability to be equal concerns. Integrity made sense, but it took me a moment to get behind the idea that availability was a security concern. I was not and am not alone in this reaction. A lot of people have this reaction. Even people that should know better, like some developers I've worked with, have had this reaction. But, not having access to your data can have serious consequences. Imagine not being able to access your bank account! You have to be able to get to your data. 

Confidentiality: When users think about Information Security, this is generally what they think about. It is typically the type of breach that makes for headlines. The disclosure of private information.  

Integrity: The data you are minding has to be accurate. Making decisions with incorrect data leads to all kinds of problems, just ask someone who is trying to scrub their credit card rating of a false report or identity theft.

Availability:  Finally there’s availability. There is no data security if users cannot access their data. 

The Wild West of Old

In the Wild West of old settlers faced many risks. The environment was hostile. The weather, wild beasts, bandits, and of course, a native population made it very risky to be a settler. Yet people were driven by the opportunity of a new life and a place to claim as their own. 

Business has always operated with risk. Indeed, risk is required in business. Business is competitive. There are winners and losers. In order to get the spoils, in order to get an advantage over their competitors, the greatest business people, the greatest leaders need to take risks to get ahead.

After more than twenty years of the commercialization, the Internet remains a vast frontier with weak security--a lot like the Wild West of old. It provides ample opportunities for modern day bandits to wreak havoc on today’s Internet settlers. Like the frontier of bygone days, the Internet provides a new way to for people to live and make money. Despite the risks we continue to use the Internet at an ever expanding rate! 

The Internet: A Modern Wild West

The Internet was conceived and built as an open system. Government, universities and large businesses at the root of the foundation of the Internet shared a common purpose and interest in having and maintaining an open Internet. For decades these open standards fostered a high-level of engagement and usage by participants. 

As the Web commercialized the Internet, those groovy open standards emerged as an on-going vector for attacks. In the 90s, attackers were often individuals writing prank viruses that were mostly intended to cause a bit of disruption and draw attention to the prankster and his l33t h4xs0r sk1lz. Nowadays there are serious and coordinated threats by organized criminals and governments to scan, monitor and infiltrate systems for all types of misuses. Information Security continues to grow in importance for governments, businesses and individuals. Vast data disclosures by retailers and governments have become a feature of our news. Spying, theft and sabotage have made way for even more insidious attacks like misinformation. And then there's GenAI, poised to generate all types of automated mischief spiked with intelligence.  

Security exploits continue to emerge at all levels of the stack. As one part of the infrastructure is tightened up, millions of new code is distributed to millions of systems. The attack surface grows faster than our defenses.

And yet, even as the threats mount, old problems persist! E-mail has suffered mighty abuse. The true source of the e-mail is easily forged. Phishers pretend to be from a known service or source. They masquerade as trusted interlocutor and get marks to disclose information they meant to keep secret. Users are bombarded by these types social engineering attacks that are made more effective when forging email through an open-relay mail server. Improvements have been made to the e-mail infrastructure; both servers and clients have gotten better. Nowadays, it has become common for email operators to utilize new mechanisms to insure mail has proof of authenticity. 

DevOps to the Rescue

Security threats emerge very quickly. They often put Ops and Dev on high alert reacting to new threats. Quick action is necessary to implement security patches and maintain operations. Even a flawless security operation will be faced with unexpected challenges on today’s Internet. Zero day security threats, serious threats that emerge without any prior notice, require the type of rapid response, central control, communication and automation that a fully functioning DevOps environment provides. 

The Security Perspective - Risk Mitigation and Monitoring Tools

The Security Perspective

1. Growing roll of security
2. Regulatory and industry compliance
3. Zero day threats require constant vigilance
4. Suite of monitoring systems

The ubiquitous threat and constant reporting of all manner of security breaches is finally starting to elevate security concerns within the enterprise. Companies historically were willing to give lip service to security, but they were a lot less likely to commit to costly security programs and additional time and effort to enhance security. Security is complicated and time consuming. When security is added as varnish over an existing process or product it will be ineffective. Security must be addressed throughout the life cycle of the product and throughout the organization. Increasingly security is being promoted within the organization. C-level executives are being appointed to guide security horizontally throughout the organization. 

Security is about reducing risks. But risk cannot be completely eliminated. If you are going to do something, anything, there is some risk involved. If you want to completely eliminate risk, do nothing, put yourself in the closet and close the door. It should be noted, that security is a process, not a destination. You need to continually reevaluate your security position and adapt to changes. Modern applications need to be regularly tested for emerging security vulnerabilities in code, included libraries, operating environments and practices. Tactical security requires defining a perimeter, choke points, and other means to limit access to your goods. On many occasions Ops will try to define the perimeter inside out. 

While security is a concern for any organization that wants to survive, organizations in regulated industries are required to pay particular attention to security. If your business handles credit card data or health care information it will be subjected to all manner of scrutiny including extensive questionnaires, audits and regulations. Organizations need to be able to demonstrate they are handling data in a secure way. They will need to have policies that provide an overview of management’s position on the rules. They will need to have procedures that detail how policies will be enacted. Finally, they will need to document adherence to policy and procedures in order to provide evidence that the organization is adhering to those same policies and procedures. 

Security has a number of dedicated tools to assist with enforcing policies and providing evidence of compliance. These tools are monitoring tools focused on specific security concerns. Perhaps the most familiar application in this category is virus protection software. A mainstay on computers in this day, virus software scans your files for signatures of known viruses. Regular updates to your virus signatures are required in order to keep up with emerging threats. Virus scanning software does have the unfortunate impact of burdening systems with a disk intensive process. Particularly on servers, a balance must be struck between how aggressively virus scanning performs it work and keeping the system running so it can perform its function.

Monitoring Tools - DLP

Another application in this class of security monitoring software is called Data Loss Prevention (DLP). Data Loss Prevention (DLP) is used to deter and detect if data is “leaking” out of the production environment. DLP programs are installed on servers, and other systems like operators’ desktops and laptops that access secure data. These programs may also work down at the hardware level disabling USB ports to prevent downloading sensitive data (or any data at all) onto a thumb drive. They may also enforce screen savers and locks to keep prying eyes or sneaky hands off your computer when you are away from it.

Monitoring Tools - WAF

Twenty years ago, it was not uncommon for organizations to connect to the Internet with just a router and without any firewall. Firewalls are now commonplace. Increasing a requirement is a type of firewall called a Web Application Firewall (WAF). Traditional firewalls operate at the network level. They filter out unwanted traffic aimed at applications and services that could be used as a vector to launch an attack. However, a typical firewall does not distinguish between authentic web traffic and malicious traffic that is encapsulated or hidden in benign looking web traffic. This is where a WAF comes in. A WAF is smarter than a traditional firewall. It knows details about the protocol used to transmit web pages. It can discern non-conforming traffic that may exploit weaknesses in the application. A WAF can also include a white list of allowable requests that can be made to the application. 

PCI Requirements

These monitoring tools are requirements for the Payment Card Industry (PCI) standard. They increase the security of the application in real-time and provide historical logs that can be reviewed after a security incident for forensic analysis. Even when they are not required by for a certification or a standard, they are best practices. They may not all be suitable for all environments every time, but they should all be considered. A conscious decision should be made before forgoing a best practice.

"Defense In Depth" with DevOps--make that SecOps

 SecOps

I think (I hope!) we all know by now that Security failures are legion. An ad hoc or reactive stance on behalf of security is risky--not only in business terms and costs of operating, but increasingly executives are being held to account in civil and criminal courts for security failures. Business leaders that take a lax attitude toward security are going to get burned. A weak security posture will be exploited. It's a certainty. 

 

Effective security measures require Defense in Depth. Multiple people, processes and applications dedicated (in whole or in part) to security are needed in order to maintain a reasonable position to defend, detect and investigate attacks. As environments grow the number of systems that need to be protected grows. The only way to keep up your defenses in a large and/or growing environment is automation. In 2015 the term SecOps began to get wide use. Like DevOps, SecOps is concerned with Configuration Management, Monitoring and Communication. And as with DevOps, SecOps requires a high degree of automation. Many of the automation tools of DevOps can serve a dual-role and help achieve the objectives of SecOps. 

A comprehensive list of security domains that need attention for an adequate Defense in Depth includes:

• Firewalls
• Access Management
• Encryption and Key Management
• Anti-virus
• Scanning
• Maintain Secure Systems and Applications
• Logging
• Policies and Procedures

DevOps can take a primary role or assist in many of these concerns. Principally, Server Configuration Management (SCM) plays a key role in both DevOps and SecOps.  From a SecOps perspective, SCM will help deliver on they key requirements of maintaining secure systems.  The goals are different for SecOps, but all of the benefits of SCM as described for Automation are also benefits for SecOps:

• Central Management
• Homogenous System Configuration
• Homogenous Configuration of Firewalls and Network Devices
• Systems Patched with the Latest Updates

Specifically, these benefits contribute to the security objective to “Maintain Secure Systems and Applications.” In fact, as environments grow, the only way to securely management is with an SCM. So how do these SCM benefits impact security? The unabridged explanation covers all the same ground as the benefits of SCM for managing server farms and clusters. The same problems of time-consuming system management environment complexity, system drift and non-homogeneity of systems, and systems that are not patched consistently all effect security. Getting all of your systems (and networks) under one umbrella with the ability to quickly and consistently update them via automation is key to holding the security line against attackers.

Additionally, SCM will assist in these other objectives for a secure environment:

• Access Management
• Anti-Virus Installation and Configuration
• Encryption and Key Management
• Logging Installation and Configuration

In the case of Access Management, an SCM might provide direct support for the management of accounts and keys, or it may only be providing a supporting role. For the other cases, SCM will aid in the deployment and configuration of these applications and tools. SCM will deliver anti-virus software, encryption keys, and logging configurations. Logging is critical for investigating security breaches. Maintaining backups of logs for one year is a requirement for PCI. 

Automation will increasingly address the concerns of policies and procedures. An SCM system will assist in the auditing of policies and procedures. Security must be continually evaluated at all levels of the organization including automation. Auditing is part of a continual feedback look designed to maintain and improve security. It is a significant part of regulatory compliance, certifications and direct customer or vendor inspection. Increasingly companies are being held accountable and incurring downstream liability for companies that interact with them as partners or providers. This is increasing the frequency and comprehensiveness of audits being performed by customers or partners. 

Inspiration: Why finish that book about DevOps?

Eight years ago, I had a burst of creative energy and wrote a draft of a book about DevOps. Here I am now, eight years later, looking at the remnants of the book that I didn't quite finish. A lot went into getting a draft of a book written, and it turns out that a lot went into putting off finishing that draft. Here are a few things that went wrong:

• I listened to advice

At a certain point in my book writing, I heard from friends suggesting I should talk to people who had already published a book or were professional writers. You'd think this advice from experienced people in your extended circle would be helpful, but that wasn't the case for me. Looking back, all I really needed was some encouragement to finish writing. What I got was worries about all the things I "should" do. I should "build a platform." They also told me things to "don't" do. "Don't self-publish!" "I should sell my book to a publisher."  The best (worst) advice I got was, "Don't write a book. Package your content in bite size chunks for digital media." 

This advice exacerbated a problem I already had--I was trying to do too much in one book. Ultimately:

• My narrative lost focus

An excerpt from the abstract for my book will demonstrate what I mean:

DevOps is the convergence between Development and Operations, making the Internet, how it is developed, and how it operates, more efficient, effective, and secure. Amazing convergences are emerging between science, business, culture, and politics; DevOps is one of them. “Talking about music is like dancing about architecture” will no longer be a hallmark of inane comparisons, but a harbinger of new ways of seeing and doing.

I like how it starts with a definition of DevOps. But, there's too much going on in this paragraph. It's a big jump from Development and Operations to "convergences" across the entire spectrum of our collective experience. And what about this bit, “Talking about music is like dancing about architecture?” Here's how far I stretched for that. Around 1991 at the University of Kansas, Laurie Anderson gave a lecture (attended by William Burroughs). I was an AV guy in the theater where she gave this lecture, and in truth, I ran the AV for her lecture. Laurie Anderson made the comparison, “Talking about music is like dancing about architecture.” It stuck with me. But maybe including it here was an inane comparison? 😔

Meanwhile: 

• DevOps was changing in real time

The novelty of DevOps was wearing off. A lot of work was coming out about DevOps, and books were being released that were filling the same niche I was targeting. DevOps, as a phenomenon, changed significantly in the course of my writing. New constructions of DevOps emerged: DevQAOps, DevSecOps, or even this mouthful, DevQASecAuditOps. I tried to incorporate some of these emerging variations, but ultimately, I fell behind the eight ball, and: 

• I gave up

So here we are, eight years hence from a failed book writing attempt and I'm ready to give this another go. And why would I pick this project back up? Well, maybe I'm just a glutton for punishment, and I'm setting myself up for giving up (again!) on a project. But, I think there are good reasons to give this another go. Firstly: 

• The DevOps phenomenon continues

DevOps is no longer a new buzzword. It has evolved into a lot more than a nifty idea: it's processes, tools, skills, business functions, jobs, in short, a market. It's also become an important aspect other activities and goals, like QA and Security. The DevOps impact will expand and include other business functions, like Governance, Risk and Compliance (sooner than some may realize).

And in some cases, expected (or wishfully hoped for) outcomes, never happened. Some thought making Ops more like development would bring about the end of Ops (i.e. NoOps) . And while it is true that these days a developer can do more with less need for dedicated Ops, Ops has not gone away. On the contrary, the need for constant operations in application service (SaaS) environments and complex interactions with 3rd party systems has expanded the surface of Operations. On the Dev side, things are also changing. Advances in software development and tools like GenerativeAI, are actually lowering the barrier of entry for an increasing number of  Development activities. Instead of DevOps becoming synonymous with NoOps, maybe DevOps is becoming synonymous with NoDev! 

Finally, I've changed:

• I know more about myself

I have a better sense of myself and my purpose in writing this book. I always had a good idea about my intentions, and I think I captured it well:

The Internet has been the engine of my professional career. I have 20 years of experience in San Francisco and Cambridge at software companies that have helped make the Internet what it is. This book, my story, my DevOps trip, is a microcosm of the Internet during this epoch of the Information Revolution.

But expectations got in the way, and I didn't finish telling my story. I'm ready to pick myself back up, shake off other people's ideas about what I should be writing, and finish this book. And while I am at it, I will take the opportunity to make it better. In my first effort, I spent too much time trying to write to someone else's idea of my audience. I struggled with how technical to make it. I shied away from including old work controversies because I imagined they might offend friends and former colleagues. On the other hand, my past companies:

WebLogic

BEA

Kenamea

Banta Integrated Systems

RR Donnelley

Axeda

International Data Group (IDG)

gave me stories to tell. Now with a little more wisdom (I hope!), I'm ready to just tell my story, and let any reactions that may (or may not) come fall where they may. So, here's to 2024 and new (old) goals! Stay tuned!

DevOps weighs more than Dev and Ops

Time flies and some things remain--including old blog posts. From eight years ago:

Why write a book about DevOps?