During the early days of my career, I used a variety of development environments, including the most popular Turbo C along with FoxPro, PowerBuilder, and Delphi before finally settling down with Microsoft Visual Studio. The first line of code that I have ever written was in QBasic running on Microsoft DOS. The editor had useful features like adding the line numbers and automatically converting the statements to uppercase. Hitting F5 would run the program instantly without having to switch to the command prompt.
The family of Visual Studio had a variety of tools bundled together — Visual C++, Visual Basic, Visual InterDev, Visual J++. During the late 1990s, when Microsoft started to see the Java threat looming large, it used Visual Studio as its ultimate weapon to combat the competition.
I was fascinated by Visual Studio for its powerful integrations with the operating system, databases, and design tools. The WYSIWYG interface combined with drag and drop canvas delivered ultimate productivity. And of course, the IntelliSense feature that brought the super cool code completion to the IDEs.
Delphi, PowerBuilder, and even Oracle Forms 2000 tried hard to beat Microsoft development tools but could make only make a little impact.
From the days of Turbo C to the latest browser-based development environments, IDEs have come a long way. And they are about to change some more.
The Changing Dynamics of Software Development
The last five years have seen a dramatic change in the software development lifecycle. The concept of Infrastructure as Code followed by the evolution of DevOps culture left a strong impact on software development. Open source movement had also played a critical role in influencing the future of IDEs. The changing dynamics forced development tool vendors to go back to the whiteboard and redesign the IDEs from the ground up.
Here are a few trends that changed the face of IDEs:
- Polyglot: Gone are the days where an application was coded in just one language targeting a single stack. For a long time, developers embraced Java or .NET religions to develop applications. In today’s world, developers are expected to know at least three languages to be productive in their job. Cloud and microservices enabled businesses to pick best of the breed languages and tools for an application.
- Cross Platform: After polyglot, the next big change came in the form of cross-platform compatibility. Each line of code should run seamlessly across a variety of desktop environments, browsers, mobile devices, tablets, and even wearables. Existing tools are insufficient to develop cross-platform apps.
- Collaboration: The open source movement combined with DevOps culture made collaborative development an important aspect of SDLC. Source Code Management (SCM) has become an integral part of development. The emergence of Git and Github made collaborative development much simpler.
- Build Management: Continuous Integration and Deployment (CI/CD) is a key pillar of DevOps. IDEs support one-click commit to the SCM which will immediately trigger a build process which will in turn fire a series of automated tests. This continuous feedback loop shrunk the cycles required to ship software. IDEs need to effectively participate in this process.
- Extensible: In the current context of SDLC, IDEs are much more than intelligent editors. They need to support emerging languages, scripting environments, declarative markup languages, and plugins for third party integration. IDEs are maturing to be platforms by themselves.
- Microservices: Microservices-based applications are assembled from a set of modular services. The shift from monolithics to microservices is influencing the thought process of developers. They need to have access to the entire stack during the development and testing phases.
- Multiple Target Deployments: The code written by a developer makes its way to the public cloud, bare metal server, a VM, a container, or even gets compiled into a standalone OS (Unikernel). Of course, the traditional challenges of targeting X86, AMD64, ARM, and other architectures still exist.
The recent acquisition of Cloud9 IDE by Amazon is an indication of what is in store for the community. Who would have thought that an IaaS provider offering computing, storage, and networking services transform into a most powerful platform company?
And other technologies such as Eclipse Che are ushering a new wave of IDEs in the software development world.
Cloud9 IDE can connect to existing code repositories hosted on Github, BitBucket, Gitlab and others. It can also be configured to talk to a database server. A configured workspace can be easily shared with other team members.
Developers can connect Cloud9 IDE to their own VM via SSH. This provides immediate access to the dependencies and runtimes.
Applications developed in Cloud9 IDE can be deployed to a variety of targets including Heroku, Microsoft Azure, Google App Engine, and Cloud Foundry.
AWS is evolving fast to become the largest platform company of our times. EC2 is the new OS, S3 is the internet file system, Aurora is the new RDBMS, and finally AWS Lambda is the polyglot runtime of the internet. Amazon may not be owning an operating system or a language, but it is transforming to be the meta-OS and meta-platform company. The competition cannot underestimate the power of AWS Lambda and its impact on the developer community.
Amazon’s acquisition of Cloud9 IDE will result in many interesting scenarios. AWS lacks the right set of tools for writing IAM (identity and access management) policies, CloudFormation templates, AWS IoT Rules, Chef Cookbooks and Recipes for OpsWorks, Stored Procedures for Aurora, and an integrated shell to interactively run CLI commands. Cloud9 would fill major gaps that exist in current AWS offerings.
Eventually, AWS will move every aspect of coding and scripting to Cloud9. Developers will be able to write, debug, test, and publish AWS Lambda functions from a single, unified environment. With the integration of AWS CodeCommit, Cloud9 would automatically commit the source code. AWS CodePipeline will bring CI/CD and build automation capabilities to the platform while AWS CodeDeploy will push the artifacts to EC2, Lambda, or ECS.
Amazon may include blueprints for IAM policies, Lambda functions, CloudFormation templates, ECS task definitions as readymade templates that developers can modify.
Cloud9 will help Amazon establish its dominance in the cloud market.
This move from Amazon has challenged Microsoft in multiple ways. Visual Studio doesn’t have an online, browser-based version that tightly integrated with Azure. Microsoft has done very little to incentivize loyal .NET developers to target Azure. Though Visual Studio has become cross-platform, it’s yet to get the level of integration that would empower Azure developers. Despite owning a large community of C# developers, Microsoft is lagging behind in offering a cloud-based IDE.
The acquisition is also an endorsement for other cloud-based IDEs such as Codenvy.
Started as eXo IDE in 2012, Codenvy is a popular cloud-based development environment. Like most of the elastic workloads, Codenvy workspaces are distributed across multiple nodes, which scale independently. The source code is kept in sync across all the nodes. The environment is optimized for multi-branch checkouts, continuous and incremental compilation, and faster deployment.
Codenvy started with the premise that every developer should be able to get cracking with the code without having to spend time setting up, installing, and configuring the environment. The concept of workspace provides a sandbox that comes with everything that a developer needs. This dramatically reduces the time to modify existing applications or setting up a development environment for new applications.
Some of the recent enhancements to the service include universal workspaces, on-premises deployment of the IDE, and tighter integration with Docker.
One of the key differentiating factors of Codenvy is agile development. Organizations can connect to Jira, Github, Jenkins, and other tools enable continuous development. Developers work on a feature branch in a shareable workspace which can be opened to other team members for immediate feedback and testing. Workspaces can be cloned for enabling instant reviews without disrupting the original workflow.
Behind the scenes, Codenvy uses Docker to make workspaces portable. Each workspace consists of a source code repository, project-specific artifacts, and multiple runtimes packaged as Docker containers. This tiered architecture makes Codenvy modular and portable. Through the concept of workspace recipes, developers can easily replicate environments within Codenvy’s cluster or even on-premises. Even if the developers don’t use Codenvy IDE, they can still take advantage of workspaces. Each Docker container comes with support for SSH and Git to provide direct access to the command line if needed.
Codenvy is one of the main contributors to Eclipse Che, an open-source Java-based developer workspace server and cloud integrated development environment modeled around the same architecture of Codenvy IDE. Besides Codenvy, IBM, Red Hat, Samsung, SAP and Microsoft are actively contributing to Eclipse Che.
We will take a closer look at Eclipse Che in one of the upcoming articles.
Feature image: Cloud9 IDE