Devops

Vanakkam all In current world, companies are rushing towards switching their application from private datacenter(DC) to Cloud providers who provide various services including compute, networking, storage, security etc. The main reason for switching from DC to Cloud revolves around the DC cost, efficiency, scalability. But soon, will we be witnessing them migrating back from Cloud to Private Datacenter considering the unprecedented price hike, unused services, unused resources, confusion in service selection etc and also server manufacturers offering the hardware in smaller size, AI powered processors which occupies less space comparing to olden days. Example | Dropbox When we talk about moving back to DC due to unplanned cloud services usage and its effect on costing, there are several companies out there who have already moved back to their private DC or planning to move back as challenge to showcase that they can built an cost effective, efficient, planned DC on their own instead spending a huge budget on cloud Dropbox In a well-publicized move, Dropbox decided to shift away from Amazon Web Services (AWS) to its own custom-built infrastructure. This decision was primarily motivated by the need to control costs and improve performance, as managing their massive amounts of data on AWS was becoming increasingly expensive. “It was clear to us from the beginning that we’d have to build everything from scratch,” wroteDropbox infrastructure VP Akhil Gupta on his company blog in 2016, “since there’s nothing in the open source community that’s proven to work reliably at our scale. Few companies in the world have the same requirements for scale of storage as we do.” Its the backward approach. Now, Dropbox has its own advanced AI driven Datacenters across. Their strategy on building a Datacenter is interesting and amazing. They have come up with their own checklist, stages, planning in acquiring a place before Datacenter is being officially set. Interesting checklist | DC site selection process: Dropbox before it stages a DC, it involves in following process Site Selection Process Power Space Cooling Network Security Site Hazards Operations & Engineering Logistics Rental rate Utility rate Rental escalator Power usage effectiveness Supporting Infrastructure Design Expected cabinet weight with dimensions and expected quantity Increased risk due to construction delays Inadequate monitoring programs, which would not have provided the necessary facility alerts With above all selection process, the team comes up with a Score card. Based on the score, they decide the site location and then work on the DC setup. Large Vs Small DC space : The technology advancement is moving towards having small servers, small rack rack space and facility to easily upgrade the hardware or enhance the existing hardware. We have providers who can help in hardware upgrade lease agreements. Consult our CubenSquare Experts for Migration : Reach out to our experts for – Move back to Private Datacenter setup Compare existing Cloud pricing Vs DC setup and its pricing forecast We understand your application, customer base, thought process and provide Cloud/DC solution Cost optimization solution in existing Cloud Summary : Probably, in next 5 years, we can see several companies moving back to private datacenters from cloud considering the temptation of using services which they don’t need, excessive usage of resources, lack of knowledge in choosing the right service resulting in enormous price hike

Get to know the difference between – Stateful Vs Stateless  

Kubernetes  

In this Blog lets learn about the Real Time Deployment Strategy Transition Watch this Video to know more  

Check out the difference between Version 1.23 and Version 1.24

The Easy Way – YAML Writing CubenSquare — IT Training | Certification | Job Placement

What is PVC ?

Learn about Deployment Volume mapping here.

What is Persistent Volume — get a outline here !!

Traditional to Virtualization to Containerization Watch Video to know more !!      

Devops Engineer works with different stake holders/teams to create and implement software systems Devops Engineer needs to be ready to work on multiple tools including any new tools emerging in the market Build Pipelines from fetching code to deploy applications on different environment Documentation : Document all the tasks being performed System analysis — Understand the current technology being used and work on improvement Develop solutions to achieve zero downtime application deployments Configure a robust monitoring & alerting system — Respond to issues proactively and not reactively Recommend performance enhancements by deep dive analysis of the infrastructure Understanding of Agile methodologies Hands-on experience in Source code management tool, CICD tool, Container orchestration tool, monitoring & alerting tool, ticketing tool Experience in any one Cloud providers — AWS/Azure/GCP

Site Reliability Engineer – The term ideated by Google and this role has been gaining more attention day by day .  A role dedicated in focussing on OBSERVABILITY, RESILIENCY, RELIABILITY AND MONITORING . Even though SRE Engineers , Devops Engineers can be set with a generic set of roles & responsibilities , organizations are forming their own job description according to their current requirement, environment and also considers the developers requirement . Because SRE engineers are there to support developers and make sure the applications are hitting smooth delivery . SRE Role Recently I met with Muthu , SRE lead in a reputed MNC . According to Muthu, SRE roles are defined according to the environment we work. The responsibilities are being added/removed as per the surrounding teams requirements, skill set . For example , if the developers team claims that they can work on AWS-EKS setup as they have bandwidth , then SRE team stands down allowing Developers to explore around AWS-EKS and just provides suggestions on demand.   The core responsibility of a SRE engineer Maintain high reliability and availability for software applications Participate in ~15% of the production incidents and find all possible way of fixing the issues permanently Automate the mundane tasks and avoid human errors. Example – Restart the services when there is an event reported, executing log rotation script manually when there is a threshold issue reported, rebooting the server etc Setup a robust Monitoring, Logging & Alerting system. Capture all logs, analyse , monitor and take proactive actions to avoid issues or application degradation . Track metrics such as availability , uptime performance , latency and error count. Define SLI & SLO by collaborating with Product owners. SLI : Service Level Indicators – SLI could be the number of successful requests out of total requests. SLO : Service Level Objective – You can set the SLOs once you have determined the baseline system performance Perform proof of concepts across existing tools to include new features which will help improve the current system. Compare existing tools with new tools and explore the options, advantages over current tools and take decisions in implementing the right tools for the environment Incident post-mortems : Write incident root cause analysis , find out the core reason behind the issue and prevent it from happening again Collaborate with cross departments : Closely work with developers to understand their application needs from platform standpoint, understand the blockers and start providing solutions to make the life easier for developers . Left shift to L1 operations team : Find the mundane tasks being performed by team and find easy way to implement/deploy those using one touch tool like rundeck , teamcity, Jenkins, concourse etc. Post implementation , left shift the task to L1 Ops team who can handle the tasks without engineering intervention . This will give enough space for Engineering team to work on product development     Summary : SRE role is like Ice cream flavors , each company have its own unique flavor according to their environment setup and requirement. OBSERVABILITY, RELIABILITY , RESILIENCY , MONITORING

Introduction The smart commit is basically an Integration between GITHUB and JIRA instance. This will help us to reduce duplicating the work of updating the JIRA comments and helps to track the corresponding changes from the particular JIRA ticket. With the help of Smart Commit, You can: • comment on issues • record time tracking information against issues • transition issues to any status defined in the JIRA Software project’s workflow. Enable Smart Commit: Follow the official JIRA documentation to enable Smart Commit: https://support.atlassian.com/jira-cloud-administration/docs/enable-smart-commits/ Create Client ID and Secret: Create the Client ID and Client Secret with Jira instance on your GITHUB organization. • Go to your organization setting. • Click “OAuth Apps” under “Developer settings” • Then click “ NewOAuth Apps” on the right side of the page • Provide the following details; o Application name — Name of the application o Homepage URL — Your JIRA instance URL o Authorization callback URL — Your JIRA instance URL • Click “Register application”. Once you completed this, now the Client ID and Client Secret will be generated. Smart Commit commands: The basic command-line syntax for a Smart Commit message is: <ignored text> <ISSUE_KEY> <ignored text> #<COMMAND> <optional COMMAND_ARGUMENTS> Any text between the issue key and the Smart Commit command is ignored. There are three Smart Commit commands you can use in your commit messages: • comment • time • transition COMMENT Description Adds a comment to a JIRA Software issue. Syntax <ignored text> ISSUE_KEY <ignored text> #comment <comment_string> Example JRA-34 #comment corrected indent issue Notes The committer’s email address must match the email address of a single JIRA Software user with permission to comment on issues in that particular project. TIME Description Records time tracking information against an issue. Syntax <ignored text> ISSUE_KEY <ignored text> #time <value>w <value>d <value>h <value>m <comment_string> Example JRA-34 #time 1w 2d 4h 30m Total work logged Notes This example records 1 week, 2 days, 4 hours and 30 minutes against the issue, and adds the comment ‘Total work logged’ in the Work Log tab of the issue. • Each value for w, d, h and m can be a decimal number. • The committer’s email address must match the email address of a single JIRA Software user with permission to log work on an issue. • Your system administrator must have enabled time tracking on your JIRA Software instance. WORKFLOW TRANSITIONS Description Transitions a JIRA Software issue to a particular workflow state. Syntax <ignored text> <ISSUE_KEY> <ignored text> #<transition_name> comment <comment_string> Example JRA-090 #close #comment Fixed this today Summary: This helps us to Develop faster saving time by manually providing the status in every JIRA ticket. It also helps the Program Manager to track the changes done for any ticket easily without requesting them offline to keep the ticket updated.

Introduction In this Blog, let’s do a comparison between a Normal Deployment Tool like Rundeck with Continuous Delivery Tool Spinnaker Problem Statement with Rundeck: 1. Get Rid of Custom Scripting — It is very Expensive 2. Process of Handing Over is Manual — Moving artifact from One Region to Another Without Manual Process 3. As of now, there is NO visibility and Audit done having Release Management Process (Promoting the versions to higher region) 4. Managing Similar configs in Kubernetes Manifests like Anti-Affinity or changes to Readiness probe can be centralized and Easy to maintain Need for Continuous Delivery Tool: Basic requirements: 1. Easily Orchestrate the Deployment and to allow us to Enable Control in every stage 2. Provide required Information about the Deployment 3. Allow us to securely Promote/Deploy the Artifact across Environments 4. Provide options to choose between Deployment strategies 5. Rollback to previous Healthier versions easily, whenever required. Spinnaker Advantages: • Easy to Onboard and Deploy Applications — UI is Easier to create Pipelines • Manage Pipeline as Code • Customise Easily with Simple Extensions • Visibility and Diagnostics • Declarative Spec for Common Strategies • Easy Access control Modes • Manual Judgements — Create Workflow with approvals. • Automated Risk Analysis — AutoPilot mode analysis Logs and Metrics • Rollbacks are Easier Comparison to Other Tools and Advantages of Managed Delivery: As of now, the deployments are done with Kubernetes Manifests — Kubernetes doesn’t have the power to take care of Delivery process. CloudFormation or Terraform — They don’t try to ensure High availability Powerful Pipelines: Deployment Strategies: Declarative Spec for Common Strategies. Spinnaker treats cloud-native deployment strategies as first class constructs, handling the underlying orchestration such as verifying health checks, disabling old server groups and enabling new server groups. Spinnaker supports the red/black (a.k.a. blue/green) strategy, with rolling red/black and canary strategies in active development. We can set Rolling Deployment for Staging Environment and Blue Green for Production environment Manual Judgements: Slack Integration: Interesting Features: Environments shown in a Single Page: Source Code — Recent version and the Commit msg deployed is shown: Pin Feature: Marking an Artifact as Bad: Final Judgement: These Modern Features available in Continuous Delivery Tools like Spinnaker makes it incomparable to a normal Deployment tool like Rundeck which handles everything based on the script provided

Netflix is a well-known example of a company that has effectively integrated DevOps principles and practices into their software development and delivery processes. The company has a large, complex technology stack and a high volume of traffic, making it critical for them to be able to quickly and efficiently release new features and fix issues. INTRODUCTION TO NETFLIX AND DEVOPS Netflix is an online streaming service that offers a wide variety of movies and TV shows. DevOps is a set of practices and tools that enable software development teams to build, test, and deploy applications quickly and reliably. Netflix and DevOps have a strong relationship. DevOps helps the Netflix development team quickly and reliably deploy new features and updates, while Netflix is a great example of how DevOps can be used to deliver high-quality products faster. DEVOPS AND NETFLIX Netflix uses DevOps to quickly and reliably deploy new features and updates. The Netflix development team uses DevOps to build, test, and deploy applications quickly and reliably. This allows them to quickly and reliably deliver new features and updates to their customers. The Netflix development team also uses DevOps to ensure that their applications are running smoothly and efficiently. By using DevOps, they are able to quickly identify and fix any issues that may arise. Here are some of the ways Netflix has leveraged DevOps: Automation: Netflix has automated many of its manual processes, including continuous integration and deployment, testing, and monitoring. This helps the company quickly and efficiently release new features and bug fixes. Microservices Architecture: Netflix has adopted a microservices architecture, which allows for faster and more flexible development and deployment of individual components of their application. Culture of Experimentation: Netflix encourages its engineers to experiment and try new things, which helps drive innovation and improve their processes. Emphasis on Resilience: Netflix places a strong emphasis on building systems that are highly resilient, which helps ensure their services are available even in the face of failures or outages. Overall, Netflix’s adoption of DevOps practices has allowed them to deliver new features and improvements faster and more reliably, while also improving the overall stability and resilience of their systems

Here are some comparisons of popular DevOps tools with movie characters, along with simple explanations: Jenkins as Tony Stark (Iron Man): Jenkins is like Iron Man, the genius inventor who creates powerful technologies to help him fight battles. With Jenkins, DevOps engineers can automate their build, test, and deployment processes, just as Iron Man creates his high-tech suits to give him an advantage in battle. Docker as Ant-Man: Docker is like Ant-Man, the superhero who can shrink down in size to fit into tight spaces. With Docker, developers can package their applications and dependencies into small, portable containers that can run on any infrastructure. Ansible as Black Widow: Ansible is like Black Widow, the master spy who can infiltrate any organization and get things done. With Ansible, DevOps engineers can automate and manage IT infrastructure from a single control node, just as Black Widow can accomplish any mission she’s given. Kubernetes as Thor: Kubernetes is like Thor, the powerful god who can control lightning and thunder. With Kubernetes, DevOps teams can manage and scale containerized applications with ease, just as Thor controls the elements with his mighty hammer. Terraform as the Hulk: Terraform is like the Hulk, the unstoppable force that can reshape the world around him. With Terraform, DevOps teams can manage their infrastructure as code, just as the Hulk can transform and reshape his body to overcome any obstacle. Git as Captain America: Git is like Captain America, the superhero who always stays true to his principles and never gives up. With Git, developers can track changes to their code over time and collaborate with others on the same project, just as Captain America works with his team to fight evil and protect the world. Nagios as Hawkeye: Nagios is like Hawkeye, the sharpshooter who can hit any target with precision. With Nagios, DevOps teams can monitor their IT infrastructure and quickly detect and resolve issues, just as Hawkeye can take out enemies with ease. Grafana as Doctor Strange: Grafana is like Doctor Strange, the sorcerer supreme who can see into the future and predict what’s coming. With Grafana, DevOps teams can visualize and analyze data from their IT systems in real-time, just as Doctor Strange can see into other dimensions and predict what’s coming. Prometheus as Vision: Prometheus is like Vision, the android with superhuman abilities who can analyze and understand complex data. With Prometheus, DevOps teams can collect and store metrics from their IT systems and use them to make informed decisions, just as Vision can use his advanced intelligence to understand complex situations. ELK Stack as the Avengers team: The ELK stack, which consists of Elasticsearch, Logstash, and Kibana, is like the Avengers team, a group of superheroes with different skills and abilities who work together to save the world. With the ELK stack, DevOps teams can collect, store, and analyze log data from their IT systems, just as the Avengers work together to defeat their enemies and protect the world. These comparisons use Avengers characters to make the DevOps tools more relatable and understandable to those who may not be familiar with them. They also provide simple, easy-to-remember descriptions of what each tool does and how it can benefit DevOps teams.

In recent years, DevOps and Site Reliability Engineering (SRE) have emerged as two popular approaches for managing software development and operations. While both methodologies aim to improve the quality, speed, and reliability of software systems, they differ in their focus and approach. In this blog post, we will explore the differences between DevOps and SRE and help you understand which approach is right for your organization. What is DevOps? DevOps is a software development methodology that emphasizes collaboration and communication between development and operations teams. The goal of DevOps is to reduce the time between code development and deployment, while maintaining a high level of quality and reliability. DevOps teams work to break down silos between developers and operations teams, so that everyone is working together to build and deploy software.DevOps teams also rely on automation tools and processes to reduce manual errors and streamline workflows. The key principles of DevOps include: Collaboration: Developers and operations teams work together to build and deploy software. Automation: Automation tools and processes are used to streamline workflows and reduce manual errors. Continuous Integration and Delivery (CI/CD): Software is developed, tested, and deployed quickly and reliably. Monitoring and Feedback: Performance metrics are monitored to identify issues and provide feedback for continuous improvement. What is SRE? Site Reliability Engineering (SRE) is a discipline that focuses on the reliability and scalability of software systems. SRE teams are responsible for designing, building, and maintaining highly available and scalable systems, while also ensuring that these systems are secure, fault-tolerant, and cost-effective. SRE teams work closely with development teams to ensure that new features are developed with reliability and scalability in mind, and that existing systems are continually improved to meet changing business needs. The key principles of SRE include: Service Level Objectives (SLOs): SRE teams define and measure SLOs to ensure that systems are meeting business needs. Automation: Automation tools and processes are used to reduce manual errors and increase efficiency. Monitoring and Alerting: Performance metrics are monitored, and alerts are triggered when issues arise. Incident Response: SRE teams have well-defined incident response processes to quickly address and resolve issues. DevOps vs. SRE: What’s the difference? The primary difference between DevOps and SRE is their focus. DevOps focuses on breaking down silos between development and operations teams and streamlining the software development lifecycle. SRE focuses on ensuring the reliability and scalability of software systems, often through automation and monitoring. Another key difference between DevOps and SRE is their approach to incident response. DevOps teams typically rely on ad-hoc incident response processes, while SRE teams have well-defined incident response processes in place. SRE teams are also more likely to use automation tools and processes to address incidents quickly and efficiently. Which approach is right for your organization? Ultimately, the choice between DevOps and SRE will depend on the specific needs of your organization and the nature of the software being developed. If your organization is looking to improve collaboration and communication between development and operations teams and streamline the software development lifecycle, DevOps may be the right choice. If your organization is looking to ensure the reliability and scalability of software systems and has a focus on automation and monitoring, SRE may be the right choice. In conclusion, DevOps and SRE are two distinct approaches to managing software development and operations. While they share some similarities, they differ in their focus and approach. By understanding the differences between DevOps and SRE, you can make an informed decision about which approach is right for your organization.

Our featured video, “A Day to Day Activities of a SRE Engineer,” takes you on a captivating journey into the world of SRE through the eyes of the talented Surya. Surya is a seasoned SRE Engineer with years of experience in managing complex systems, ensuring their reliability, scalability, and performance. In this video, he walks you through his day-to-day activities, offering valuable insights into the responsibilities and challenges that come with being an SRE Engineer.

Challenges : – Single place for seamless validation and deployment of salesforce project – Minimize human interference – Decrease the release time – Scheduled pull was limited – Development team have to locally pull the latest code and do Ant deploy Goals: – Simplifed approach – Reliable approach – Innovative – Faster deployments Solution : – Move to Jenkins Pipeline [Jenkins has two pipeline methods : Scripted pipeline & Declarative Pipeline] [Declarative pipeline method is easy to write,read & we have an option to generate the pipeline from GUI menu options] – Used BlueOcean Plugin to visualize the pipeline process & results [ Blueocean is a plugin with easy visualization] – Declarative pipeline with multiple stages with view & debug errors Timeout issues: – The build pipeline included tests too which added time to overall build. This resulted in timeout issues – To fix this ,we increased the heapmemory Plugins used : – Blue Ocean – JavaMelody – Git – Ant – SAML – Pipeline Plugin Benefits: Shorter build times Release times which decreased from more than 1/2 a day to around 2 hours Continuous feedback mechanism for the developers to fix issues instantly

Introduction: In today’s rapidly evolving technological landscape, career transitions have become more common than ever before. If you’re currently working in a non-IT field but aspire to venture into the world of DevOps, you’re not alone. DevOps, which combines software development and operations, offers exciting opportunities for individuals looking to leverage their skills and embark on a dynamic and rewarding career path. In this blog, we will guide you through the steps of shifting your career from a non-IT background to DevOps successfully. Assess Your Skills and Identify Transferable Ones: The first step in transitioning to DevOps is to evaluate your current skill set and identify transferable skills that can be applied to this field. While you may not have direct experience in IT, look for skills such as problem-solving, analytical thinking, project management, collaboration, and communication that are valuable in the DevOps domain. Gain Knowledge and Familiarize Yourself with DevOps: To make a successful transition, it’s crucial to acquire knowledge about DevOps practices, tools, and methodologies. Start by understanding the core principles and concepts of DevOps, such as continuous integration, continuous delivery, and infrastructure automation. Explore online resources, enroll in relevant courses or certifications, and join DevOps communities to stay updated with industry trends and best practices. Learn Essential Tools and Technologies: DevOps relies on a wide range of tools and technologies to automate processes, manage infrastructure, and facilitate collaboration. Familiarize yourself with popular DevOps tools like Git, Jenkins, Docker, Kubernetes, Ansible, and AWS/Azure. Hands-on experience with these tools will not only enhance your skill set but also demonstrate your commitment to learning and adapting to the DevOps environment. Gain Practical Experience: Building practical experience is crucial to proving your competence and transitioning into DevOps roles. Seek opportunities to work on real-world projects or contribute to open-source projects. Consider volunteering for cross-functional teams or taking on side projects that involve aspects of DevOps. This practical experience will not only strengthen your technical skills but also provide you with valuable insights into the DevOps workflow. Network and Seek Mentorship: Networking plays a pivotal role in any career transition. Attend industry conferences, meetups, and workshops to connect with professionals in the DevOps field. Seek out mentorship opportunities where experienced DevOps practitioners can guide you, provide advice, and share their insights. Engaging with the DevOps community can open doors to potential job opportunities and help you stay motivated throughout your career transition journey. Customize Your Resume and Highlight Relevant Skills: Tailor your resume to showcase your transferable skills, practical experience, and relevant certifications. Emphasize your ability to adapt, learn quickly, and work collaboratively in dynamic environments. Highlight any instances where you have applied DevOps principles or used relevant tools during your previous work experience. A well-crafted resume will help you stand out and demonstrate your potential value as a DevOps professional. re for Interviews and Continuous Learning: Once you start applying for DevOps positions, be prepared for technical interviews that assess your understanding of DevOps concepts, tools, and problem-solving abilities. Practice answering common interview questions and be prepared to discuss your experiences and projects. Additionally, remember that learning is an ongoing process in the IT industry, so continue to invest time in upgrading your skills and staying up-to-date with emerging technologies and trends. Conclusion: Transitioning from a non-IT background to DevOps requires determination, continuous learning, and a willingness to adapt. By assessing your skills, gaining knowledge, acquiring practical experience, networking, and customizing your resume, you can position yourself for success in this dynamic field. Embrace the challenges and opportunities that come with the transition, and with persistence and dedication, you can make a successful leap into the world of DevOps. Good luck on your career journey!