Development Best Practices for Hybrid Cloud: Part 2
Development Best Practices for Hybrid Cloud: Part 2
In the second part of this series, we look at some of the remaining best practices for working in a hybrid cloud environment.
Join the DZone community and get the full member experience.Join For Free
Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.
Whether we are developing a microservice, UI, or a configuration script, it is worthwhile to spend enough time architecting the solution. In hybrid cloud environments, it is preferred to architect solutions taking into account patterns such as event-driven, stateless, interface contracts, messaging, command query responsibility segregation (CQRS) etc. which can greatly help to scale applications as desired while avoiding complexity. Also, if we have enough use cases for a certain functionality, it is recommended to use available tools rather than trying to create a solution.
Documentation as Code
This is one of the most interesting topics of development. There are many tools out there which can provide different levels of documentation in which some are static, where a developer has to explicitly document, and some are implicit, where the tool itself generates the docs. We need a hybrid approach to completely cover the documentation needs. It should start with naming the variables/parameters and method/function with appropriate verbs and human-readable names, followed by using tools such as Swagger, RAML, Spring docs, etc. to get the inventory of the service itself. This should be complemented with using API management or versioning tools to host the actual design diagrams and other relevant artifacts, including architectural design decision (ADD) documents. Care should be taken that we don’t over-engineer to convert one form to other, just to call it self-documented.
Security is the most important aspect of any development in hybrid cloud. With the introduction of layered architecture, it is a big question on where to authenticate and authorize a particular resource. This is further complicated by introducing gateway and third party into the mix. Rule of thumb is to always adhere to the CIA principle, which is that confidentiality, integrity, and availability of the resource, should be enforced. This can be achieved by progressively increasing the security controls as we move closer to the source of the resource. A few key things to remember are:
- User IDs should be separate from process or app IDs;
- There should be a limited number of admin users for a resource and always track why a user had to login to exercise his credentials;
- Creating separate services to handle security or using native libraries is a debatable question, care should be taken to consider the business case, performance implications and effectiveness before making the decision.
With layered architecture, scalable infrastructure and multiple availability zones, traditional testing methods are not sufficient to thoroughly test. Care should be taken to account for use cases like: data writes in one zone and immediate reads in another zone before data synchronization completion, timer based triggers and guaranteeing avoidance of duplicate processing of same event, sticky sessions, caching etc. It is recommended to create reference apps to run through the use cases with deployments and loads comparable or greater than production.
Along with proper server selection it is important to select correct deployable type. Six factors that need to be considered for selection of a deployable type are purpose of the application/service, where the deployable will be deployed (cloud with scalable resources or a standalone box), components of the deployable, the mechanism through which it is deployed, time taken for deployment (important for on-demand scaling) and expected performance/feedback of the deployable.
Collaboration & Retrospective
With the rapid growth of the virtual technologies, it is becoming mainstream to work off-site and off-shore. Having a good collaboration tool can greatly improve productivity of the team. Tools like Jira and Version One are some of the best tools available. Collaboration should account for anything which will enable the progress of the development without impeding the work whereas retrospective should evaluate the source of impediment and take corrective actions to minimize the recurrence of the impediment in an iterative approach.
API-First Design & Development
With the availability of hybrid cloud technologies, it gives more flexibility to create the design first to suit the needs, rather than worry about the supporting infrastructure. API-first design also helps to be creative, focus on fit for use and upfront interface design, which gives stakeholders and consumers a clear idea on what to expect. This also speeds up the development process by enabling parallel development on both sides of the interface. Swagger and RAML are most widely used tools for API first development.
As the complexity of the project increases, configuring the workstations for development can get very cumbersome. There are many standard templates available and also tools like Maven and Visual Studio provide the capability for custom archetypes. In some cases Docker images can also be used to fine-tune development environments for specific projects.
The 3 Es of Code
Effectiveness, Ease and Elegance are the three Es of Code. Code should be effective without redundancy, and well-modularized. Ease of understanding is critical to maintain, enhance and support, we may need to forgo some efficiency in favor of simplicity. Elegance in code can only be achieved in well-thought-out code which is properly modularized, sufficiently documented and appropriately followed humanly-readable naming convention. User variable, aesthetic appearance of code, alignment, etc. are also key components of how elegant code is. Most organizations define the structures which include indentation, spacing, formatting etc. and other conventions defined in organization-specific check style templates.
This concludes Part 1 and Part 2 of this series. This is by no means an exhaustive list, but it is most commonly used list. As technologies and coding styles evolve, so do the best practices. As a developer, it is key to constantly focus on evolving these best practices to suit the need of the team and the project as a whole. Following 3E’s of coding as mentioned above can help us strive to evolve these practices.
Opinions expressed by DZone contributors are their own.