A recurring argument in the DevOps community is whether the word DevOps should exist within a job title. Most people close to DevOps think it’s a potentially harmful anti-pattern which indicates a misunderstanding of what DevOps is all about. A few years ago I agreed with this, but I’ve now changed my mind.
Yes, DevOps is a culture, a mindset and all of those good things.It is about how people work together much more than automation.I also appreciate the argument that labelling individuals and teams with DevOps potentially introduces a silo where we are trying to solve a problem of siloes.
With all of that recognised, I’m still more than happy to now call myself a DevOps Engineer.
There were lots of job titles that didn’t exist 10 years ago.Agile Coaches, Social Media Managers, Data Scientists and Mobile App Developers for instance.Those fields evolved and there are now recognised experts in those fields who know how to apply the tools and help organisations be successful with them.
DevOps is the same.It is maturing as a movement and there is now enough specialist knowledge in the niche that people can build significant niche expertise, work within it full time, and even build long term careers as DevOps Engineers.
Definition Of A DevOps Engineer
DevOps Engineers are the people who sit between or within Development and Operations and use automation across the SDLC to reduce the cycle time from development to production.
These Engineers will bring knowledge across Development, Testing and Operations and help with gluing those areas together to ease the transition of code across them.
They will have deep technical skills in tools such as Puppet, Chef, Ansible, Vagrant and Docker, and use these tools to help their organisations deliver better software, faster and more reliably. They will also likely understand cloud and how to use infrastructure automation to leverage this to best effect.
As important as the technical knowledge is what we call the ‘DevOps Mindset’ – a personality type and approach that can help the IT organisation move from traditional ways of working, break down siloes, and collaborate more effectively. Technical skills alone do not make an effective DevOps Engineer.
Why This Matters
To me, this all sounds meaty enough to be a full time roleand a career path.Therefore, why shouldn’t it also have it’s own name to identify it by?
I’ve always been pragmatic about this, but my main interest in this is how accepting DevOps Engineers as a job title might help to overcome the DevOps skills crisis – the huge shortage of people in industry who have this skill set and the fact that as an industry, we have still have no sustainable path to creating these people.
By accepting DevOps Engineers as a job and a career path, I think the definition of one would become more concrete. There would be more of a shared understanding over what it means, rather than savvy build and release engineers or system administrators re-badging themselves.
More people could align themselves to DevOps Engineering and work towards obtaining this recognised skill set.
Visibility of DevOps activities within the business would grow, and budgets would be created to support DevOps rather than it being an under the radar activity happening under other functional siloes.
Training for DevOps Engineers might emerge, and one day, it might even end up as a University Level course.
All of these things would help DevOps expand as a movement and practice in industry, which is ultimately a good thing for the sponsoring organisations and anyone who works in IT. Here at Contino, the more we interact with customers around DevOps, the more I realize this is the path things should take.
Industry studies and market indicators show the exploding growth of the DevOps movement, and it’s for one simple reason – in today’s application driven economy, DevOps teams have proven that they can build, test and ship applications faster than the traditional IT approach.
Businesses compete on the efficiency of delivering applications to meet the demands of the critical mass. Enterprises need the latest business applications to meet new service demands of their customers, accessed in new ways such as over mobile devices. In an application-driven economy, apps are developed and delivered via the cloud more rapidly than ever before; fast time to market is key for success and staying a step ahead of the competition.
As a result of this incredibly dynamic environment, IT teams have adopted new processes such as “continuous integration, continuous development” (CI/CD) – a radical departure from the waterfall model of application development that’s been around for decades. These people and groups within organizations that are leading the charge on CICD or agile development – to meet economic demands for the exploding cloud and mobile market place – are called “DevOps”.
However there are three big barriers that are still slowing down the time to market for apps. Unfortunately, there’s not much the DevOps folks can do since the problem lies in how underlying enterprise IT infrastructure, and specifically the networking products such as application delivery controllers (ADCs), have not kept pace with this evolution.
The reasons application delivery to market is still too slow, as well as recommended solutions, include:
Network admin “Human Latency”: ADCs are usually purchased by the network admins that sit within the CIO–led IT teams. As a result, the DevOps and application developers don’t have access to ADC devices. Since app developers need ADCs to test the efficacy of the apps they are building, they have to connect with the networking teams and request access to ADCs…and wait for permissions. This typically takes weeks because of the complexity involved with setting up a custom environment per app developer per app!
In a world where it takes 20 seconds to fire up a server, the human latency (measured in weeks) associated with provisioning an ADC is simply unacceptable.
The solution: A fully programmable , self-service ADC that the app developer/DevOps folks can themselves setup within seconds using RESTful API and scripting tools. DevOps needs an ADC that has zero touch provisioning, is able to auto-discover the compute/app environment, and can auto-create and auto-scale.
Distributed Microservices-based app architectures: Microservices have fundamentally changed how apps are built, maintained and scaled. Instead of a monolithic “black box” app that sits in one location with a “reusable or even disposable lego-block” architecture, Microservices can be written in different programing languages, loaded on various hardware and hypervisor platforms, and, most importantly, deployed across various on-premise and cloud locations.With this heterogeneity comes complexity in managing all these different environments which leads to cost and delays associated with rolling out a new application.
The solution: An application delivery architecture that can span, serve and scale all locations, while remaining one device to manage from a management perspective.
Geographically dispersed Dev, Test and Production teams: Many companies have the development and testing of apps done in a public cloud, but because of data sensitivity issues (or compliance) they have to run production copy of the app on on-prem data centers or private clouds.Imagine for a minute what this means – completely different environments across various cloud/on-prem locations!When doing development or testing, a certain ADC can be used on-prem – but it’s a different ADC for the real world. There can be unexpected surprises in terms of how the app actually behaves, performs and scales in a real deployment.
Solution: DevOps teams need the same consistent environment across public, private and on-prem data centers. More importantly, if the setup and operations of ADCs across environments is identical, it saves a lot of complexity and costs.
The goal of the DevOps group is to make the organization successful by increasing IT performance and delivery. It aims to make life of an app developer and tester simpler, allowing enterprises to develop and roll out their own apps faster than the competition. From a recent study by Puppet Labs, analysts noted: “We wanted to test the hypothesis that IT performance actually does make a difference to organizational performance. We found that IT performance strongly correlates with well-known DevOps practices such as use of version control and continuous delivery. The longer an organization has implemented — and continues to improve upon — DevOps practices, the better it performs. Companies with high IT performance are twice as likely to exceed their profitability, market share and productivity goals, giving them a strong competitive edge. “
Now more than ever, companies need to be committed to the DevOps model to keep up with the constantly changing business landscape. New approaches to DevOps addressing the challenges of today’s dynamic environment are available for companies to leverage for the benefit of their customers. The timing could not be better – it is now. However, an evolution of the underlying IT infrastructure such as the application delivery controllers (ADC) is not just desirable but mandatory.
About the Author/Ranga Rajagopalan
Ranga Rajagopalan, CTO and Co-Founder of Avi Networks. Over the last 15 years prior to co-founding Avi Networks, Ranga has been an architect and developer of several high-performance distributed operating systems as well as networking and storage data center products. Before his current role as CTO, he was the Senior Director at Cisco’s Data Center business unit, responsible for platform software on the Nexus 7000 product line. Joining Cisco through the acquisition of Andiamo where he was one of the lead architects for the SAN-OS operating system, Ranga began his career at SGI as an IRIX kernel engineer for the Origin series of ccNUMA servers. Beginning his journey with a Master of Science degree in electrical engineering from Stanford University and a Bachelor of Engineering in EEE from BITS, Pilani, India, he now has several patents in networking and storage.
Editors note: This article represents the authors own opinions on the tools he mentions. We welcome others to join in the conversation about their opinions and experiences with these tools and similar ones. Important to note that they do not represent the opinion or beliefs of devopsy.kinsta.cloud or its editors.
Recently I began looking for an application performance management solution for .NET. My requirements are code level visibility, end to end request tracing, and infrastructure monitoring in a DevOps production setup.
DotTrace is clearly the most well-known tool for code level visibility in development setups, but it can’t be used in a 24×7 production setup. DotTrace also doesn’t do typical Ops monitoring.
Unfortunately a Google search didn’t return much in terms of a tool comparison for .NET production monitoring. So I decided to do some research on my own. Following is a short list of well-known tools in the APM space that support .NET. My focus is on finding an end-to-end solution and profiler-like visibility into transactions.
New Relic was the first to do APM SaaS, focused squarely on production with a complete offering. New Relic offers web request monitoring for .NET, Java, and more. It automatically shows a component-based breakdown of the most important requests. The breakdown is fairly intuitive to use and goes down to the SQL level. Code level visibility, at least for .NET, is achieved by manually starting and stopping sampling. This is fine for analyzing currently running applications, but makes analysis of past problems a challenge. New Relic’s main advantage is its ease of us, intuitive UI, and a feature set that can help you quickly identify simple issues. Depth is the main weakness of NewRelic. As soon as you try to dig deeper into the data, you’re stuck. This might be a minor point, but if you’re used to working with a profiler, you’ll miss CPU breakdown as New Relic only shows response times.
Dynatrace is the vendor that started the APM revolution and is definitely the strongest horse in this race. Its feature set in terms of .NET is the most complete, offering code level monitoring (including CPU and wait times), end to end tracing, and user experience monitoring. As far as I can determine, it’s the only tool with a memory profiler for .NET and it also features IIS web request insight. It supports the entire application life cycle from development environments, to load testing, to production. As such it’s nearly perfect for DevOps. Due to its pricing structure and architecture it’s targeted more at the mid to enterprise markets. In terms of ease of use it’s catching up to competition with a new Web UI. It’s rather light on infrastructure monitoring on its own, but shows additional strength with optional Dynatrace synthetic and network monitoring components.
Ruxit is a new SaaS solution built by Dynatrace. It’s unique in that it unites application performance management and real user monitoring with infrastructure, cloud, and network monitoring into a single product. It is by far the easiest to install, literally takes 2 minutes. It features full end to end tracing, code level visibility down to the method level, SQL visibility, and RUM for .NET, Java, and other languages, with insight into IIS and Apache. Apart from this it has an analytics engine that delivers both technical and user experience insights. Its main advantages are its ease of use, web UI, fully automated root cause analysis, and frankly, amazing breadth. Its flexible consumption based pricing scales from startups, cloud natives, and mid markets up to large web scale deployments of ten-thousands of servers.
AppNetta‘s TraceView takes a different approach to application performance management. It does support tracing across most major languages including database statements and of course .NET. It visualizes things in charts and scatter plots. Even traces across multiple layers and applications are visualized in graphs. This has its advantages but takes some time getting used to it. Unfortunately while TraceView does support .NET it does not yet have code level visibility for it. This makes sense for AppNetta, which as a whole is more focused on large scale monitoring and has more of a network centric background. For DevOps in .NET environments however, it’s a bit lacking.
Foglight, originally owned by Quest and now owned by Dell, is a well-known application performance management solution. It is clearly meant for operations monitoring and tracks all web requests. It integrates infrastructure and application monitoring, end to end tracing, and code level visibility on .NET, among other things. It has the required depth, but it’s rather complex to set up and obviously generates alert storms as far as I could experience. It takes a while to configure and get the data you need. Once properly set up though, you get a lot of insight into your .NET application. In a fast moving DevOps scenario though it might take too long to manually adapt to infrastructure changes.
AppDynamics is well known in the APM space. Its offering is quite complete and it features .NET monitoring, quite nice transaction flow tracing, user experience, and code level profiling capabilities. It is production capable, though code level visibility may be limited here to reduce overhead. Apart from these features though, AppDynamics has some weaknesses, mainly the lack of IIS request visibility and the fact that it only features walk clock time with no CPU breakdown. Its flash-based web UI and rather cumbersome agent configuration can also be counted as negatives. Compared to others it’s also lacking in terms of infrastructure monitoring. Its pricing structure definitely targets the mid market.
Manage Engine has traditionally focused on IT monitoring, but in recent years they added end user and application performance monitoring to their portfolio called APM Insight. Manage Engine does give you metric level insight into .NET applications and transaction trace snap shots which give you code level stack traces and database interactions. However it’s apparent that Manage Engine is a monitoring tool and APM insight doesn’t provide the level of depth one might be accustomed to from other APM tools and profilers.
JenniferSoft is a monitoring solution that provides nice real-time dashboarding and gives an overview of the topology of your environment. It enables users to see deviations in the speed of transactions with real time scatter charts and analysis of transactions. It provides “profiling” for IIS/.NET transactions, but only on single tiers and has no transaction tracing. Their strong suit is clearly cool dashboarding but not necessarily analytics. For example, they are the only vendor that features 3D animated dashboards.
Conclusion: There’s more buzz around on the APM space than a Google search would reveal on first sight and I did actually discover some cool vendors to target my needs; however, the field clears up pretty much when you dig for end-2-end visibility from code down to infrastructure, including RUM, any web service requests and deep SQL insights. And if you want to pair that with a nice, fluent, ease-of-use web UI and efficient analytics, there’s actually not many left …
About the Author/ Thomas Kunz:
I am an innovation architect focusing on IT in the context of the disruptive changes through the convergence of Social, Mobile, Information and Cloud and digital business transformations. After more than 20 years of experiencing one of the biggest IT enterprises in the world and its projects, programs and people, I am now helping customers overcoming the challenges through the omnipresent trend of digitalization. Follow me here http://twitter.com/@thom1309 or find me at my blog http://blog.smile-it.at or at http://www.productwings.com
Ansible Tower is used in a variety of different ways, from traditional configuration management, to custom application deployment, to the orchestration of zero-downtime rolling updates. Companies like Gawker Media use Ansible to deploy their sites more than 10 times an hour. NASA uses Ansible to update security vulnerabilities and to patch manage nasa.gov weekly. Enterprises that make money delivering applications via the web find that Ansible Tower excels at removing IT bottlenecks, automating repetitive tasks, and accelerating the delivery of applications to market.
For IT operations, rolling updates with zero downtime is a very common orchestration pattern that has been discussed at length, but let’s take a look at how Ansible Tower fits earlier into the software development lifecycle and removes bottlenecks in operations, as well as in in development and test.
Ansible Tower offers a number of benefits in the SDLC, specifically to:
Drive consistency between environments
Enable self-service
Improve automated testing
Development
A typical day in the life of an application developer may be to: check out code, make changes, test locally, check in changes.
During the course of this work, the development environment may become infected with small configuration tweaks and hand-crafted software stacks that differ dramatically from the environment that production code is ultimately deployed to.
In fact, a common problem in many organizations is that the development environment may not exactly (or even closely) match what’s in QA, Stage, and Release. Generally, the further away from production you get, the less and less the environments look the same. (Not just the obvious examples like software library versions, but more subtle items like configuration settings, authentication details, etc.).
Inconsistency between code and the software stack that supports the application is a common cause of software errors and resulting production downtime. With Ansible, a playbook captures the desired state of the stack and even the entire environment. Ansible Tower provides a push-button interface that templates how a playbook should be run — deploying consistently and with repeatability.
With Ansible Tower, a playbook is run from a job template, which specifies the parameters and environment details of how to run the playbook, with all of the parameters and options you would normally pass via the Ansible command line. There is no concern that the user will mistype an option or parameter to Ansible, potentially deploying to the wrong environment or with the wrong playbook arguments since the template is triggered via the push of a button (or API.)
Not only do these templates drive consistency between deployments — each time the button is pressed the same result is expected — but they also encourage a tremendous amount of playbook reuse: Multiple job templates can be created that launch the same identical playbook with different parameters. This enables the same playbook to be used between environments or stages of release. The job template can use the same playbook, but target different inventories (corresponding to different stages of release or different environments), pass different options, even use different credentials.
This drives consistency between releases, even across different stages, by ensuring that the same steps to automate provisioning and deployment are followed between each stage.
Screenshot of how to use different job templates with the same playbook, passing different parameters from the user to deploy into different environments
When combined with the the role-based access control capabilities of Ansible Tower, playbooks can be deployed at the push of a button, but in a controlled and easily-audited way. This allows an organization to spread the power of Ansible to any of its users. Even users unfamiliar with Ansible can run playbooks that others have written.
These features are commonly used to enable self-service provisioning of development environments by the developers themselves.
Typically, developers manually construct a development environment that starts out only loosely coupled to the production software stack and deviates further and further over time. Alternatively, developers are forced to request a new development environment from operations teams, usually incurring delays that proliferate throughout the software development lifecycle and lead to late deployments, missed deadlines, and lost business.
Tower enables developers to check out and provision their own development environment, built from scratch and 100% consistent with the software stack used in test, stage, and production — because it is built with the same playbook. Developers log into Ansible Tower and, under RBAC, see only the job templates that they have permission to access and deploy.
Developers do not require any knowledge of Ansible or the playbook. They can provide new parameters and options, specifying perhaps the release tag of the application to be deployed or fine tuning the deployment to fit within the constraints of the environment. The playbook handles provisioning the new servers (e.g. by calling out to VMware or Amazon Web Services), deploying and configuring the software stack, and the actual application under development. The developer presses a few buttons in Ansible Tower, goes and gets a cup of coffee, and then returns to a newly 100% provisioned environment. Tear down and re-provisioning is a snap, so a new environment for pristine development can be deployed at any time.
QA
A typical day for QA might look like this: Program a CI tool to automatically build the codebase periodically, deploy to a test environment, run tests, report results.
At most shops, some of this work is generally automated, usually building the latest code and the deploying the latest code artifacts into test. Deployment of the application stack may not be automated (or easily refreshed between test cycles), leading to the same consistency problem as in development,or worse, because test environments and artifacts are potentially reused between test cycles. Here again, the reuse of playbooks between environments through the Ansible Tower job template will promote consistency between stages of release.
Additionally, the same Ansible Tower self-service capability that can be provided to developers can also be provided to testers. QA may write their own playbooks for automated testing and Ansible Tower can be used to delegate responsibility to QA staff who are not Ansible experts or aren’t comfortable running Ansible on the command line.
In addition to self-service, it is very common to use Ansible Tower in conjunction with a Continuous Integration system in QA to automate not only application deployment in test, but provisioning of the application stack to refresh the test environment between tests.This way, Ansible Tower provides a complete RESTful API that powers the Ansible Tower user interface and makes it possible to programmatically invoke Ansible Tower to do any function that can be performed via point and click in the UI. In this way, a CI tool like Jenkins can be connected to Tower to launch job templates for automated testing. Jenkins is configured to call the Ansible Tower API to launch a specific job template that invokes an Ansible playbook to provision a new QA environment, deploy and configure the appropriate software stack, the correct version of the application, and the test suite. Automated testing can be performed and the environment decommissioned, all within one or more playbook runs.
Just as in development, this ensures that the test environment is consistent with all release stages — that what is being tested is the same as what was developed and what is being deployed into production. Test environments can quickly be provisioned and deployed 100% from scratch, improving your ability to test and to speed up the application to production delivery.
When used in conjunction with with a CI tool like Jenkins, the combination is more powerful than with a CI tool alone: Jenkins can kick off Ansible playbooks to provision environments and deploy the latest code as part of any Jenkins CI job, but under the framework of role-based access control, inventory management, and aggregated job output that Ansible Tower provides.
As you adopt Ansible Tower into Operations, consider also the benefits of Ansible and Ansible Tower throughout your software development lifecycle. Apply automation to eliminate bottlenecks through every stage of release and accelerate the delivery of your applications to market.
Let me know how you are using Ansible Tower in your efforts – we want your input!
Dave Johnson, Senior Technical Director, Ansible. Dave started his career at Red Hat prior to its IPO, ultimately building and leading the sales engineering organization that penetrated the US Oil & Gas, Electronic Design Automation, and Managed Service Provider markets.Prior to joining AnsibleWorks, Dave held executive positions at rPath and Bronto Software, leading engineering and services organizations that spearheaded the transformation of innovative custom solutions into repeatable Products.Dave holds a B.S. in Electrical Engineering and a B.S. in Computer Engineering from North Carolina State University. Contact info: @thisdavejohnson, Linkedin
The event will be held on Wednesday, May 29th from 6 p.m. to 9 p.m. at the Press Club, 20 Yerba Buena Lane, San Francisco, near Moscone Center, where Build is taking place.
With two of our three managing partners at Ignition Partners – Frank Artale and John Connors, having deep roots with both Microsoft and the Seattle area, the idea is that along with our 4 portfolio companies, we will bring a little bit of our Seattle heritage to the party and the conference.
We will highlight the two major Seattle-based enterprise Cloud platforms, Microsoft’s Azure and Amazon Web Services. Ignition is working on behalf of its portfolio companies, especially cloud-oriented companies based in the San Francisco Bay Area, to build our profile in Seattle with these cloud market makers.
The networking event will offer an opportunity for open access to the cloud decision makers within Microsoft and to create synergies that may lead to new projects. Attendees will be able to network with thought leaders and gain insight into both the Microsoft and Amazon ecosystems.New companies able to offer products and services that work with or on Azure may leverage new and untapped business opportunities, beyond those found in the San Francisco market.
See you at the Press Club, and remember, it’s all about the build!
About the Author/Rachel Chalmers
Rachel Chalmers joined Ignition as a principal in 2013. She sources deals in enterprise and cloud infrastructure, “big data” and the “Internet of Things”; advises portfolio companies and provides counsel on industry trends.
Prior to Ignition, Rachel worked for 13 years at the 451 Group, an independent technology industry analyst firm focused on the business of enterprise IT innovation. She was most recently the company’s vice-president of research, overseeing all work on enterprise infrastructure software. Coverage areas included hypervisors, operating systems, provisioning and automation, application development, performance monitoring and lifecycle management. While at 451, Rachel was among the first analysts to cover Opsware, BladeLogic, VMware, Splunk and Cloudera.
Before becoming a technology analyst, Rachel was a journalist in the U.S. and Australia. She helped launch Computer Week, later PC Week Australia, and was the Internet editor for Computerwire, where she wrote about software and open-source technologies.
Rachel received a BA degree in English from the University of Sydney and a master’s in philosophy, with a focus on Anglo-Irish literature, from Trinity College, Dublin. She is an advisor to the Ada Initiative, a non-profit that supports women in open technology and culture.
While many organizations are looking to agile methods to deliver mobile apps faster, they are also facing challenges in embracing the methodology across the organization. The keystone of agile for mobile apps is the focus on “the state of quality,” or the need to know if your code works, so will your app. The major problem that so many organizations are facing is this: DevOps teams are doing agile for mobile halfway. They perform nightly builds but no one is aware of the state of quality.
What’s limiting visibility into the state of quality? There are three factors:
First, unstable or limited test automation capabilities impacts the number of non-unit tests that can be run. Test automation capabilities are often similar to a slice of Swiss cheese – it looks good but there are definitely holes.
Secondly, unstable development environments cause for workarounds, such as non-scalable scripting or skipping over major factors that impact a test environment, such as weak connections to wifi. Stabilizing a development environment is so crucial to the rest of the agile mobile app development lifecycle, while workarounds are not a sustainable solution.
Finally, out of cycle tests are impacting the quality Many times, organizations keep test sections, like load testing, out of the lifecycle because of complexity. That means there’s never true insight into the state of quality during the mobile app lifecycle.
To figure out how to know where the quality stands on any given day, organizations need to take a “no code left behind” type process. Continually embedding quality into the mobile app lifecycle will assure working code and working apps.
Here are steps to achieve this:
Cut out the Swiss cheese: Combat limited test automation by implementing a wide and stable automation that meets requirements. Set those requirements before selecting an automation engine:
Do you need to interact with the device or just the app?
Do you need to analyze what is on the screen?
Do you need self-recovery in case the system crashes?
Staff Accordingly: Devices are unstable by definition. Humans are more stable. Organizations can make an environment stable by staffing it accordingly, making someone available to handle testing.
Leverage the hybrid cloud: Create an always-on test lab with a person to take care of it. This reduces traps like USB connectivity issues, breach of security guidelines, Mac support, etc. Staffing an outlier to manage a test lab WILL break your cycle.
Bring it In-Cycle: Out-of-cycle test sections will also break your cycle. Build an environment that supports a variety of test cases and brings the outliers in such as different network conditions, multiple devices connected at the same time, capacity issues and the ability to always ready for load or security testing.
Educate the organization: In embracing Continuous Quality, educate your staff on the benefits and power of using automated testing in the cloud and the results that they will see experience with their own work.
An environment that’s open and integrated and offers the least amount of limitations possible will allow DevOps to generate creativity from a comfortable place and give visibility into the state of quality. Continuous Quality is the only way to ensure your apps are working well and are released faster.
About the Author/Yoram Mizrachi
Yoram Mizrachi is the CTO of Perfecto Mobile. Yoram brings to Perfecto Mobile a wealth of experience in networking, security and mobile telecommunications. Yoram founded Perfecto Mobile after serving as the CTO of Comverse Mobile Data Division. In this capacity, Yoram handled a variety of technological aspects in mobile applications, WAP and location-based services. In 1999, Yoram was the CTO (and founder) of Exalink, which was later acquired by Comverse for $550 million. Prior to founding Exalink, Yoram held several technology-related positions in the fields of communication and cryptography.
In the past, data managers operating Oracle data systems had to rely on an unrelenting number of manuals and booklets to figure out how to efficiently maneuver around Oracle errors. The age of Google has transformed this quest, making the lives of countless developers far less painstaking. Now those facing an error that just does not seem to want to go away are also faced with a wealth of resources on the other side of a web search.
Several websites have dedicated databases and Oracle writers that work exclusively on developing content to streamline Oracle troubleshooting for individual errors. But why stop there? We compiled a list of the ten most searched Oracle errors on the Internet.
1. Invalid or Nonexistent Column Name – ORA 00904
This is a simple fix. The error is triggered by either an invalid or missing column name. An ORA-00904 can be evaded by making sure to begin a column name with a letter, only use alphabetical, numerical or special characters (and using quotations with other characters), and not exceeding thirty characters in length.
2. Unhandled Exceptions in PLSQL Code – ORA 06512
The description for this won’t bring much information; just an “ORA-06512: at line ” will show up. So what does it mean? The stack being unwound by unhandled exceptions in your coding brings about the error. There are a couple of options to managing this. You can correct whatever is causing the unhandled error, or you can write an exception handler for the error. However, due to the complexity of this, it may be best to refer to your database administrator for more help.
3. Failed to Connect with Listener – ORA 12154
For this error, the connecting name could not be located in the naming method repository, or for some reason the repository could not be found. There are a multitude of actions available to correct this, primarily involving the verification of file names, net service names and syntax.
4. Executing SQL Statement that Doesn’t Exist – ORA 00942
The basis of this message stems from attempting to execute a SQL statement that either references a table or view that does not exist or that you cannot access. You will need to check to see if the table exists, and if it does not you will need to create the table or view. If you don’t have access, speak with an administrator about this issue.
5. Invalid Username and/or Password – ORA 01017
The ORA-01017 is an error not exclusive to Oracle. All it means is that the username/password combination entered was incorrect. Checking your system parameters to make sure the ID is aimed at the proper location, and just simply re-entering the login information from there should do the trick.
6. Missing Expression Error – ORA 00936
Another quick syntax fix! This message is triggered from a required clause being left out, such as the SELECT statement being entered without an incomplete expression, or when a reserved word like SELECT TABLE is misused.
7. “Invalid Number” Error – ORA 01722
This error is being thrown due to a failed attempt to convert a character string to a number. This will happen because arithmetic functions in Oracle can only contain numeric data, and only numeric data can be added to or subtracted from dates. Find the invalid data, which sometimes can be hidden if part of a sub query, and correct it to fit within the Oracle numeric parameters.
8. Arithmetic or Numeric Value Mistake – ORA 06502
The ORA-06502 is triggered when a numeric, string, conversion, constraint or arithmetic error occurs. Many times this will result from assigning a value to a numeric variable that is larger than the variable permits, or from assigning a non-numeric value to a numeric-only variable.
9. Invalid Character Error – ORA 00911
This is a syntax error that is about as straightforward as it can get. The cause stems from a number of mistakes, such as starting an identifier with a character other than a letter or number, or not enclosing identifiers with special characters in double quotes.
10. Improper Clause for SQL Command – ORA 00933
The final error on our list, another syntax error, derives from an improper clause ending an SQL statement. For instance, an ORDER BY clause cannot be used to create an ordered view in Oracle, but perhaps the error was triggered when the ORDER BY clause was attached to a CREATE VIEW statement. Also, additional indented lines can trigger the problem.
Concluding thoughts
These are the most searched errors either because they are the most commonly occurring ones, or because they are difficult to resolve. The fortunate thing about Oracle is that so many errors derive from simple syntax mistakes that do not require a great deal of knowledge to mend. Of course, as you have seen with this list, working past them and preventing them requires a strong base understanding of how to operate efficiently within Oracle by keeping track of parameters and the proper protocol for actions.
The other prominent set of Oracle errors come from issues involving the network that Oracle is accessed through. By establishing a strong rapport with your network administrator and keeping aware of the details of your network (memory space on drives, who can access what, etc.) these kinds of errors can largely be circumvented.
While this list is not exhaustive by any means, it should help in not just providing brief descriptions and solutions for the ten errors mentioned, but also by putting you in the proper mindset to take on other Oracle errors beyond the list and work to operate your data with a superior adeptness.
About the Author/Judd Robins:
As Executive Vice President, Judd is instrumental in driving the overall direction and revenue growth of the consulting services division of TekStream Solutions. He works collectively with his team to launch territory campaigns to increase customer awareness, excel in quality of solution delivery, and established a presence in the region as a leading Gold Oracle Partner for Enterprise Portal and Enterprise Content Management technologies.
The idea of DevOps being a competitive advantage is not a new one. Service providers, software sellers, and internal IT frequently use this argument to justify all kinds of investments. But is there any real merit to this argument? Is DevOps truly a source of sustainable competitive advantage? Or is it simply just hype and a new way to sell a product / service?
Here are some of the more popular points of view from both sides of the aisle.
“Yes Absolutely”
“No, Go Take A Hike”
Speed is sexyIn the mobile, social, and web world customers expect speed and responsiveness. Bringing an idea to the market faster than your competitors is definitely an advantage and DevOps allows us to do just that.
DevOps is not the only fish in the seaAgreed that speed is sexy. But at this given moment there are multiple technologies / philosophies out there that claim to do the same – i.e. cloud, big data, analytics etc. What makes DevOps so different?
DevOps is hard to replicateWhile purchasing tools is easy, the real benefit lies in getting the culture and process right. Any organization that can get that right will be able to form a sustainable competitive advantage.
Same has been said about other strategiesRemember when outsourcing started. It too was touted as a sustainable competitive advantage. Now it is the de facto strategy for IT erasing any advantages that the early adopters had. DevOps, if it does take off, too will follow the same path.
New IT operating modelDevOps represents a new way for enterprise IT to operate. It breaks down the silo structures and unlocks the value trapped within the existing organization.
Enterprises are not start-upsJust because it worked in a start-up environment does not mean that it can work in a large enterprise.
Listening to customersSpeed is only one equation of DevOps advantage, the other is faster feedback loops so that you can determine that you are going in the right direction. Combine the two and you have a powerful competitive advantage.
Not an IT responsibility / competencyIsn’t that what most organizations already do? I have my entire business / product / marketing org. focused on just that. The last thing I need now is IT to jump in and muck it all up.
The new Software Delivery LifeCycle (SDLC)DevOps represents a new way for enterprise IT to operate. It breaks down the silo structures and unlocks the value trapped within the existing organization.
Just good marketingThis is just repackaging of an old wine into a new bottle…DevOps is just a new thing. Like all other fads this too will pass.
My Take
Allow me to be the quintessential consultant and speak from both sides of my mouth. DevOps is and is not a competitive advantage. Now before you close the browser and move on, let me explain.
DevOps in the short term is most definitely an advantage. Moving an organization from Traditional to a DevOps approach is not an easy task. Any corporation that can successfully achieve this transformation will be the first to reap its benefits – from faster speed to market to being more responsive to their customers. And the benefits are real! Ask Netflix and Etsy, who have been able to out innovate their competitors and gain a sizable lead in the market.
However, in the long term, as more and more firms invest in DevOps the advantage will continue to shrink. DevOps, if you strip all the marketing jargon and go down to the most basic definition, is about reorganizing the internal plumbing of IT (i.e. how IT performs the various tasks within the software delivery lifecycle). And while in the short term plumbing can allow you to do some neat stuff, at the end it’s only internal plumbing and rarely a source of lasting competitive advantage.
To see this is action, look at the automotive, financial, and then our very own Information Technology industries. In all three examples, the company that was able to transform was able to establish an early sizeable lead, reap the rewards, and the rest of the industry forced to catch up eventually.
In automotive industry, early investment in lean and TQM earned Toyota customer loyalty and a significant lead over its traditional competitors. And while the lead lasted for a decade (short time in an industry where product lifecycles are 4 – 5 years), competitors quickly started to invest and catch up. You can now argue that U.S. manufacturers are at par with Toyota in both quality and speed. Where the competitors have still not caught up is in perception.
In the 1970s it was not unusual for a home buyer to wait for up to 90 days to get a credit decision and a loan, as per “industry standards” in those days. Citibank rearranged its internal processes to give buyers a decision in 30 days. It took the industry by storm. Competitors eventually caught up and now 30 days is the norm.
And as for our very own, Information Technology industry…outsourcing was considered to be a competitive advantage for many of the first movers. Like other strategies, it too required a structural change to make it happen. Many of the initial pioneers were able to cut IT costs by over 30% and establish a cost advantage over their competitors. But within a decade competitors copied, banked the savings, and eroded the cost advantages.
In my opinion, DevOps too will follow a similar path. A few leaders will emerge (already happening), they will set the pace of change for the industry, and the rest will have to follow….whether they like it or not.
About the Author
Mustafa Kapadia is the Service Line Leader for IBM’s DevOps practice, a business advisory practice focused on helping large enterprises transform their software & application delivery. He has over 17+ years of experience in the tech. space, both as a service provider and a management consultant.
Prior to joining IBM, Mustafa was a management consultant with Deloitte’s Strategy & Operations practice. He lives in San Francisco Bay Area, is an avid blogger (when time permitting), a speaker, and adviser to start ups.
We are seeing a wave of wearable products coming to market. According to IDC research 19.2 million shipments this year will build to a global market of 111.9 million units by 2018. The long predicted rise of wearables is upon us.
Fitness trackers were in the vanguard then came smartwatches. Pioneers like Pebble are now being joined by Google’s Android Wear platform, the Apple Watch, and Microsoft Band. New form factors are emerging, from the Moto Hint earpiece to Google Glass. It feels a lot like the early days of feature phones and MP3 players. But, the wearables industry is lacking some guiding principles.
To create a truly compelling experience, manufacturers and designers in the world of wearables need to consider the following:
Superhuman extension of you
Wearables should be an extension of you that gives you super powers. Like any good technology, they need to make life easier. Wearables should allow you to see better, hear better, think better, and optimize your performance. Wearable technology should be your personal force multiplier, a mentor, an assistant, and a confidant. And it needs to be smart enough to know when to switch roles.
The world is the interface
When wearables and the digital world intersect the world becomes the interface, not a black piece of one inch, four inch, or 10 inch glass. We need to break away from the tyranny of the touchscreen. Consider the Apple Watch giving map directions using haptic feedback. You should be able to control things at a distance. We need new ways of interacting with the world by simply looking, saying, pointing and gesturing.
Act cool and be polite
Devices that are present with us all day hearing and seeing what is going on, need to be smarter about how they join the conversation. They shouldn’t talk when you’re talking. They should only interject when they have something relevant to say or show you. They need to get to know you, to learn, and to customize their behavior for you. You don’t want a notification when you’re in the middle of an important conversation. Wearable technology must be able to act cool and be polite, just like a person.
Respect the human condition
Wearables need to improve the human condition, not make it worse. You must be able to maintain privacy and trust, especially for devices that witness your whole day. We need technology that doesn’t enslave, but rather that enables us. The loveable, intelligent operating system from the movie Her, not the Big Brother state of George Orwell’s 1984.
Keep me present
Wearables shouldn’t focus on glanceability, they should focus on keeping us present. Anticipate things for us so we don’t have to drift out of the present to worry about the future. The power of now is that now is the only moment we have. Too often our technology takes us away from the here and now, making us less present and less human.
The right fit
Technology that you wear all the time has to be incredibly comfortable. It has to fit right, or you won’t want to wear it. Most hearing aids are customized for the person wearing them. We’ll see more custom fitting of wearable technology in the future. The only technology that’s more personal than wearables will be embedded, but that’s another story.
Invisible or fashionable
If you can’t make your wearable technology invisible at least make it fashionable. People don’t want to feel socially awkward. When Nielsen surveyed consumers 62% said they wish wearables came in forms besides wrist bands and watches, and 53% wanted wearable devices that look more like jewelry. Most of the time technology should not be seen or heard.
The perfect nexus of hardware and software remains elusive right now. The iPhone moment for wearables has not yet arrived, but if designers can keep these seven principles in mind it surely won’t be far away.
About the Author/ Guy Bieber
Guy Bieber is the Director of Strategy and Innovation for Citrix. He formerly worked as the Chief Architect for Warrior Systems at General Dynamics on the first deployed wearable computing platform for soldiers called the Land Warrior System. Citrix is a global leader in mobile workspaces, providing virtualization, mobility management, networking and cloud services.
In this fast-moving, immature space, expect to spend cycles assessing where the greatest value lies for each team and the business as a whole.
The term “microservices” is popping up everywhere in software development circles. Indeed, microservices are frequently touted as The Next Big Thing in terms of how to write applications to avoid the problems of complex, monolithic architectures.
From a Devops perspective, the microservices discussion is usually related to Docker or other containers. Both share an emphasis on lightweight individual units that can be managed independently, so containers are often regarded as a natural implementation choice for a microservice architecture. But what are microservices actually?
Microservices constitute a software architectural style that approaches a single application as a suite of small services, each running its own process and communicating with lightweight mechanisms, such as an HTTP-based API. The services are small, highly decoupled and focus on providing a single “useful” business capability. Typically, microservices involve very little centralized management, may be written in different programming languages, and use different data storage technologies.
A good way to understand the microservice style is to compare it to the monolithic style, in which an application is built as a single unit. A classic example of this approach is the “standard” three-tier enterprise application, consisting of a client-side user interface, a database, and a server-side application. Changes made to monolithic applications can be both painful and costly as any change made to a small part of the application requires the entire monolith to be rebuilt and deployed.
Microservices clearly offer many advantages — notably the ability to make small changes to code quickly and efficiently, and with minimum risk. The services are organized around business capabilities, and they lend themselves to Continuous Delivery.
Some of these advantages include the following:
Small, Easy-to-understand Code
As a microservice app is responsible for only one thing it requires little code, is easy to understand, and involves minimal risks when changes are made.
Easy-to-scale, Easy-to-deploy and Easy-to-discard
Size is important. Microservices technology make it easy for developers to scale, deploy and discard apps and features. In contrast, a single change to a monolithic app requires changing the whole application.
Smaller Teams
It’s much easier and faster to work with a small team than a large one. Each small team can own a microservice and access other services via a high-level API.
Facilitates System Resilience
If a monolith application stops working a lot of functionality will stop working. In contrast, if a microservices app stops working only a small, specific functionality will be lost.
However they are not without their serious challenges, especially relevant from a DevOps perspective — such as coordinating interdependent deployments, fusing developer skills with technologies, and confronting disagreements between developers.
As developers break down monolithic applications and move complexity from within to between applications, obvious challenges come to the fore. Some of these include the following:
Coordinating Interdependent Deployments
Individual microservices are supposed to be independently deployable, but in order to provide any kind of useful functionality from the perspective of the user you typically need to get a whole set of microservices running.
Deploying microservices requires a new generation of tools that can manage a multitude of simple deployments, while tracking and managing their dependencies. These tools need to be able to bring everything together on time to deliver an app without being too rigid, for instance by supporting version ranges for services rather than fixing on individual versions. These tools should help developers to deploy different bundles of services easily, without having to ask an administrator to reconfigure the deployment tool.
Planning and configuration should be done through a single interface with a real-time view of app deployment. Essentially, developers should seek to attain the same balance of speed and efficiency that Continuous Delivery offers.
Microservices Need Skilled Developers and Operators
While there are many potential productivity boosts to separating services, tracking all of the relationships between them is vital. The team needs to know the entire development landscape and be able to test live components together.
Testing isolated services is a simple enough proposition, but testing the entire user-facing business service can be problematical.
Developer Disagreements
There will be a lot of time-consuming debate and friction when developers butt heads about the pros and cons of keeping a monolithic stack versus embracing microservices: which applications to refactor, which to rewrite, which to leave alone, etc.
The worst-case scenario: developers lose sight of the overarching system goals, focus on the service they are working on, refuse to be flexible, and resist being part of an overall team.
Finding the right set of technologies for a microservices implementation will not be a quick or simple task. As this is a fast-moving, immature space, expect to spend a lot of time assessing where the greatest value lies for each team and the business as a whole. Delivering the greatest benefits may mean adopting a hybrid system that draws on and integrates different technologies.
About the Author/Andrew Phillips
Andrew Phillips heads up product management at XebiaLabs. Andrew is an evangelist and thought leader in the DevOps, Cloud and Continuous Delivery space. He sits on the management team and drives product direction, positioning and planning.
